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ABSTRACT 


Previous  research  has  shown  that  it  is  possible  to  use  the  Internet’s  Multicast 
Backbone  (MBone)  and  associated  audio/video  software  for  the  purpose  of  Distance 
Learning.  As  more  education  is  performed  online,  the  need  arises  to  be  able  to  view  the 
content  at  the  user’s  convenience.  Through  experimental  testing,  this  thesis  investigates 
the  usefulness  and  feasibility  of  applying  networked  recording  and  storage  of  digitized 
audio  and  video,  all  via  the  MBone  for  distance  learning. 

Large  distributed  organizations  such  as  the  Naval  Service  can  economically  benefit 
from  the  use  of  the  Multicast  Backbone  and  its  associated  tools.  To  date.  Navy  and 
Marine  Corps  projects  using  video  teleconferencing  have  not  exploited  the  vast 
possibilities  provided  by  the  Internet  and  the  MBone.  This  thesis  takes  distance  learning 
one  step  farther  and  combines  MBone  audio/video  vwth  the  new  recording  tool  called  the 
Multicast  Backbone  Video  Conference  Recorder  (MBone  VCR).  This  enables  distance 
learning  as  a  viable  replacement  to  on-site  training.  It  is  technically  feasible  and 
economically  supportable  to  record  the  digital  media  that  results  from  an  MBone  session 
used  for  a  distance  learning  program.  That  stored  information  can  then  be  used  repeatedly 
and  easily  updated  to  support  changing  curricula  and  information.  Problems  and  network- 
accessible  solutions  are  demonstrated  in  this  case  study  on  use  of  the  MBone  VCR  as  a 
usable  remote  educational  tool. 
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I.  INTRODUCTION  AND  MOTIVATION 


This  thesis  investigates  the  usefulness  and  feasibility  of  applying  networked  storage 
of  digitized  audio  and  video,  all  via  the  Multicast  Backbone  (MBone)  for  distance 
learning.  The  research  follows  the  “Recommendations  for  Future  Work”  section  of  the 
thesis  “Internetworking:  Worldwide  Multicast  of  the  Hamming  Lectures  for  Distance 
Learning”  (Emswiler,  1995). 

A.  BACKGROUND 

The  idea  of  face-to-face  meetings  without  the  need  for  travel  has  intrigued 
educators  and  business  leaders  for  years.  Science-fiction  television  dating  back  to  the 
1960's  has  portrayed  the  future  as  one  in  which  people  will  routinely  communicate  over 
great  distances  using  audio  and  video.  Distance  education  has  recently  been  considered  in 
much  the  same  way.  With  impressive  advances  in  data  compression,  real-time  transport 
protocols  and  transmission  media,  the  future  seems  to  have  arrived.  Today  people  across 
the  globe  can  come  together  using  the  Internet  and  effective  audio/video  software  tools 
that  utilize  a  virtual  network  called  the  Multicast  Backbone  (MBone). 

The  MBone  uses  audio-visual  conferencing  capabilities  that  were  developed  to 
provide  scientists  with  an  easy  way  of  sharing  information  over  long  distances  in  a  manner 
similar  to  their  normal  interactions—and  in  their  normal  workplaces.  The  MBone  was  also 
developed  to  prove  the  potential  usefulness  of  this  kind  of  interaction  on  a  scale  provided 
by  the  Internet.  The  MBone  effort  has  effectively  helped  set  standards  that  can  guide 
interoperable  software  development  (Davies,  1995). 
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Since  it  began,  the  MBone  has  proven  to  be  an  important  tool  in  remote 
conferencing.  However,  most  of  the  events  last  one  day  or  perhaps  a  week  and  are  not 
broadcast  on  a  regular  production  basis.  In  the  first  quarter  of  1995,  Tracey  Emswiler  of 
the  Naval  Postgraduate  School  succeeded  in  multicasting  an  extended  class  over  the 
Internet  (Emswiler,  1995).  Her  case  study  involved  multicasting  Dr.  Richard  Hamming’s 
course,  “The  Art  of  Doing  Science  and  Engineering;  Learning  to  Learn,”  three  times  a 
week  for  an  entire  academic  quarter.  Emswiler  correctly  pointed  out  that  storir;  -md 
accessing  digital  recordings  of  past  lectures  and  conferences  is  the  next  step  ie 
evolution  of  this  technology. 

B.  MOTIVATION 

1.  What  is  the  Importance  of  Distance  Learning  and  the  MBone? 

“The  organization  that  learns  fastest  will  survive”  (Senge,  1990).  This  philosophy 
is  often  forgotten  in  a  cost-cutting  era  that  continuously  attempts  to  do  more  with  less. 
When  an  organization  is  facing  shrinking  budgets  and  increasing  costs,  training  programs 
are  often  the  first  to  receive  cuts.  Training  is  also  set  aside  when  operational 
commitments  take  students  away  from  local  training  centers.  Due  to  widespread 
geographic  dispersion,  military  personnel  often  fall  victim  to  the  philosophy  of  “I’ll  go  to 
the  class  when  I  get  back  from  deplo5mient.”  Distance  education  is  intended  to  provide  an 
alternative  to  the  usual  requirement  of  a  student’s  physical  presence  at  school  for  training 
If  successful,  distance  education  can  reduce  training  budget  expenditures  reducing  the 
need  for  travel. 
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The  MBone,  using  the  existing  Internet  infrastructure,  provides  an  interactive  way 
to  teach  and  learn.  MBone  software  is  economical  (the  tools  are  free).  It  can  be  used  to 
provide  real  content  today  and  software  capabilities  continue  to  gain  strength.  Applied  to 
distance  learning,  the  MBone  provides  geographically  remote  students  the  ability  to 
economically  and  dynamically  interact  with  the  teachers  and  other  students  using  audio, 
video,  and  other  protocol  streams.  The  convergence  of  all  types  of  information  content  on 
the  Web  means  that  Internet  access  has  become  a  crucial  requirement  for  all  organizations 
for  the  foreseeable  future.  Multicast  and  the  MBone  are  the  best  technical  solutions  for 
delivering  Internet-compatible  audio  and  video. 

2.  How  does  Video  Archiving  Apply  to  Distance  Learning? 

Distance  learning  effectiveness  improves  not  only  when  long  distance  can  be 
overcome,  but  also  when  the  timing  of  classes  is  no  longer  a  limiting  factor.  Establishing  a 
video  archive  of  the  classes  that  are  held  over  the  Internet  using  the  MBone  can  provide  a 
means  for  students  to  view  classes  at  their  convenience.  Students  on  another  continent 
will  not  have  to  watch  the  instructor  at  3  A.M.  in  their  local  time  zone.  Instead,  they  can 
watch  the  lecture  when  convenient  and  ask  any  question  using  electronic  mail.  It  will 
actually  bring  the  classroom  to  the  student  anytime  it  is  necessary  (Emswiler,  1995). 

Internet-based  distance  learning  is  not  a  panacea.  Significant  human-factors  and 
other  issues  exist  regarding  pedagogy,  effectiveness  and  ease  of  use  (Gabrino,  94).  We  do 
not  explicitly  address  those  issues  in  this  thesis.  Rather,  we  focus  on  the  technical 
feasibility  of  recording  and  distributing  digitally  archived  network-accessible  audio/video. 
Further  work  is  needed  to  maximize  the  effectiveness  of  this  new  medium. 
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C.  THESIS  ORGANIZATION 


This  thesis  is  organized  into  the  following  chapters.  Chapter  11  discusses  the 
background  of  this  work  and  other  research  related  to  distance  learning,  the  MBone,  and 
video  archiving.  Chapter  HI  provides  a  short  synopsis  of  the  problems  examined  in  this 
thesis  and  applications  of  the  results.  Chapter  IV  examines  the  protocol  and  payload  types 
used  for  digitizing  the  desired  lectures  and  conferences.  Chapter  V  explores  the  methods 
used  for  building  and  accessing  the  archive.  Chapter  VI  shows  tht  y  ipeiimental  results  of 
this  research.  Chapter  VII  summarizes  the  conclusions  dravra  from  this  work  and 
provides  recommendations  for  future  work. 

Appendices  have  been  provided  for  further  clarification  of  concepts  addressed  in 
this  thesis.  Appendix  A  is  a  glossary  of  terms  used  in  this  thesis.  Appendix  B  provides  the 
HTML  and  perl  Web  scripts  that  are  used  during  video  retrieval.  Appendix  C  is  an 
instruction  set  for  installing  and  operating  the  tools  used  for  video  storage  and  retrieval. 
Appendix  D  shows  two  recent  articles  that  detail  MBone  and  Web  content  work  that  is 
continuing  at  NFS. 
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II.  BACKGROUND  AND  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  examines  pertinent  background  work  and  continuing  research  in 
distance  education  and  the  Multicast  Backbone  (MBone).  A  short  summary  of  each  study 
is  provided  to  explain  how  they  relate  to  this  thesis. 

B.  BACKGROUND 

1.  Distance  Education 

In  order  to  understand  the  possible  applications  of  the  Multicast  Backbone  and 

video  archiving,  the  term  distance  education  or  distance  learning  must  be  defined. 

Distance  education  is  a  special  application  of  telecommunications  to 
teaching  and  learning  situations  in  which  learners  are  geographically 
separated  fi-om  teachers,  and  both  depend  on  electronic  devices  to 
communicate  (Keegan,  1983). 

Distance  education  can  thus  be  seen  as  something  as  simple  as  a  correspondence  course 
offered  through  electronic  mail  or  something  as  complex  as  interactive  video 
teleconferencing  via  satellite. 

Distance  education  does  have  its  limits.  Understanding  when  a  distance  education 
approach  might  work  is  crucial  to  any  implementation.  Applications  that  require  extensive 
hands-on  training  are  not  the  best  candidates  for  distance  learning.  Yet  something  like 
‘Math  for  Marines”  (a  correspondence  course)  might  easily  be  taught  using  distance 
education.  The  list  in  Figure  2. 1  outlines  general  situations  when  a  distance  education 
approach  can  be  productively  applied. 
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♦Target  audience  is  widely  scattered  and  it  is  not  cost  effective  or  possible  to 
have  them  travel  to  a  central  training  location. 

♦Content  or  consistency  in  deliveiy  is  so  critical  that  it  must  be  carefully 
controlled  for  accuracy  or  correct  interpretation. 

♦Content  is  too  dangerous  for  novices  to  participate  in  and  distance  education 
will  allow  for  familiarization  and  confidence  building  prior  to  the  actual 
situation. 

♦Scheduling  difficulties  arise  because  the  student  cannot  take  extended  time 
fi’om  other  critical  missions  to  attend  a  normally  conducted  training  program. 

♦The  expense  of  conducting  live  training  is  cost  prohibitive. 

♦There  are  a  limited  number  of  qualified  trainers. 

Figure  2.1  Productive  applications  of  a  Distance  Education  approach.  (Biggs,  1994) 

2.  Multicast  Backbone  (MBone) 

Video  Teleconferencing  (VTC)  has  been  the  method  chosen  for  many  past 
experiments  in  distance  learning.  However,  this  method  requires  dedicated  transmission 
lines,  special  proprietary  hardware  and  (usually)  a  dedicated  VTC  classroom.  While  there 
have  been  several  alternative  VTC  technologies  to  choose  fi’om,  all  have  these  costly 
minimum  requirements.  The  biggest  question  when  trying  to  implement  a  distance 
learning  program  is  which  alternative  is  the  most  cost  effective. 

Since  1992  a  new  Internet  development  known  as  the  Multicast  Backbone 
(MBone)  has  been  growing  in  popularity.  The  MBone  was  first  used  to  broadcast  the 
March  1992  Internet  Engineering  Task  Force  (IETF)  conference.  Since  then,  it  has  been 
used  for  numerous  global  presentations.  Primarily,  the  MBone  has  been  used  by  network 
researchers  to  collaborate  with  each  other.  It  offers  a  number  of  advantages  over  standard 
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teleconferencing,  which  instead  joins  very  few  sites  with  expensive  dedicated  transmission 
lines.  MBone  links  anyone  to  the  Internet  who  has  a  workstation  or  PC  and  a  high-speed 
connection.  The  increased  flexibility  of  the  MBone  has  resulted  in  moves  by  both  NASA 
and  DOE  to  replace  teleconferencing  with  MBone  meetings  (Kahn,  1994). 

Multicasting  gained  international  attention  (and  made  rock-and-roll  history)  when 
it  was  used  to  carry  20  minutes  of  the  Rolling  Stones'  "Voodoo  Lounge"  concert  tour. 

The  concert  was  carried  to  some  200  workstations  around  the  world  that  were  connected 
to  the  Internet.  Another  example  of  its  potential  was  seen  at  a  surgeons'  conference  at  the 
University  College  in  London  (UCL).  Approximately  100  doctors  in  London  and  Sweden 
watched  as  a  surgeon  in  San  Francisco  performed  a  complex  liver  operation.  As  he 
operated,  viewers  asked  questions  about  the  procedure  (Davies,  1995).  The  MBone  has 
also  provided  around-the-clock  coverage  of  space  shuttle  flights.  In  effect,  the  MBone 
provides  free,  many-to-many  video  teleconferencing  over  the  Internet. 

Specifically,  the  MBone  is  a  subset  of  the  Internet  that  is  capable  of  multicasting. 
That  is,  instead  of  sending  identical  multiple  sets  of  packets  to  each  destination  (like 
delivery  of  an  electronic  mail  message  with  multiple  recipients),  the  network  copies  each 
packet  of  information  fi'om  the  source  and  delivers  the  packets  only  to  those  destinations 
that  have  requested  them.  The  receivers  request  the  packets  by  subscribing  to  particular 
sessions.  The  receiver  must  be  on  a  network  set  up  for  multicasting  to  be  able  to  sign  up 
for  a  session.  Since  multicasting  capabilities  are  not  built  into  much  of  the  Internet,  the 
MBone  is  considered  a  virtual  network.  It  does  use  the  same  physical  topology  as  the 
Internet.  However,  real-time  audio  and  video  packets  can  require  special  handling,  and 
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therefore  are  distributed  using  a  network  of  routers  that  know  what  to  do  with  multicast 
packets. 

Van  Jacobson  and  Steven  McCanne  (of  the  Information  and  Computing  Science 
Division  at  the  Lawrence  Berkeley  National  Laboratory,  LBNL)  and  Steve  Deering  (of  the 
Xerox  Palo  Alto  Research  Center)  are  three  of  the  principal  developers  of  the  MBone. 

The  team  created  the  software  tools  used  most  during  MBone  multicast  (Kahn,  1994). 
Unlike  traditional  broadcast  methods  such  as  radio  or  television,  the  MBone  is  totally 
interactive.  The  software  created  by  the  development  team  includes  a  session  directory  to 
announce  events,  a  shared  virtual  piece  of  paper  called  whiteboard  (wb),  a  video 
conferencing  tool,  and  an  audio  tool.  The  software  enables  real-time  audio-video 
conferencing  over  the  Internet.  Participants  can  interact  using  text,  images  and  face-to- 
face  communication. 

Since  its  inception  MBone  conferencing  has  grown  exponentially,  with  traffic 
doubling  about  every  eight  months.  Right  now,  more  than  10,000  people  in  30  countries 
are  using  it  for  collaborative  work.  "Among  scientists,"  predicts  Stewart  Loken,  who 
heads  LBL's  Information  and  Computing  Sciences  Division,  "MBone  conferencing  will 
become  as  routine  as  e-mail.  And  this  will  happen  much  sooner  than  you  think.”  (Kahn, 
1995)  Despite  its  steady  growth,  special  routing  and  bandwidth  requirements  have  made 
the  MBone  somewhat  difficult  to  access.  However,  new  router  software  is  coming  onto 
the  market  that  simplifies  connecting  to  the  MBone.  MBone  connectivity  is  now  possible 
over  slower  links  such  as  128  Kbps  Frame  Relay  (Erdogan,  1996),  and  its  use  appears 
imminent  on  128  Kbps  ISDN  links  (Mihlon,  1996).  Other  advances  in  the  technology  that 


8 


allow  recording  and  remote  playback  of  MBone  sessions  are  also  being  researched 
(Holfelder,  1996).  This  type  of  approach  can  allow  individuals  to  watch  recorded  sessions 
at  any  time,  making  the  sessions  more  convenient  and  accessible  to  people  in  different  time 
zones. 

Today,  no  other  interactive  communications  tool  has  been  as  successful  at 
reaching  large  numbers  of  people.  Primary  reasons  for  this  success  include  public-domain 
software  for  multiple  platforms,  and  efficient  many-to-many  packet  delivery  using 
multicast.  With  small  advances  in  hardware  and  software  anyone  with  a  computer  and  an 
Internet  coimection  will  be  able  to  use  the  MBone.  Says  Loken,  "On  the  Internet,  I 
believe  that  1995  will  be  to  MBone  what  1994  was  to  the  World  Wide  Web.  Almost 
unknown  right  now,  Internet  videoconferencing  is  about  to  become  commonplace." 

(Kahn,  1995)  It  is  now  1996  and  the  MBone  continues  its  rapid  growth.  Getting 
coimected  remains  labor  intensive,  but  it  is  a  one-time  job.  It  appears  that  MBone 
expansion  has  not  crossed  over  into  explosive  growth,  but  the  steady  exponential  increase 
remains  impressive. 

C.  RELATED  RESEARCH 

1.  Merci  Project:  Multimedia  European  Research  Conferencing 
Integration 

The  Multimedia  European  Research  Conferencing  Integration  (MERCI)  project  is 
a  follow-on  to  the  Multimedia  Integrated  Conferencing  for  Europe  (MICE)  project,  each 
coordinated  by  UCL  (MERCI,  1996).  MICE  provided  multi-way  integrated  conferencing 
service  between  a  number  of  European  pilot  sites,  linking  various  sites  to  the  appropriate 
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communities  in  the  U.S.  MICE  demonstrated  a  range  of  possible  ways  to  internetwork 
project  partners  using  heterogeneous  computing  environments.  The  result  was  the 
interconnection  of  up  to  half  a  dozen  conference  rooms,  up  to  a  dozen  workstations,  and 
the  employment  of  conferencing  services  between  them.  In  September  of  1995  the  MICE 
project  gave  way  to  the  Multimedia  European  Research  Conferencing  Integration 
(MERCI)  project. 

The  objective  of  the  MERCI  project  is  to  provide  all  the  technology  components 
(other  than  the  underlying  data  network  itself)  to  allow  proper  deployment  of  software 
tools  for  European  multimedia  collaboration.  Figure  2.2  shows  how  MERCI  is  making 
improvements  to  the  tools  developed  during  the  MICE  project  from  1992-95. 

♦Better  integrated  facilities,  so  more  easily  used  by  untrained  users 

♦Better  capability  for  higher  quality  video,  audio  and  shared  work  space 
facilities 

♦Inter-operable  cross-platform  support  for  many  systems  -  UNIX 
workstations,  PCS  and  MACs 

♦Better  support  for  the  introduction  into  and  recording  of  multimedia 
information  in  conference 

♦  Support  for  different  network  technologies  -  mainly  over  IP;  packet-switched, 
ATM  or  SMDS  and  ISDN 

♦Inter-operation  between  workstations  running  the  multicast  Internet  and  the 
normal  CCITT  procedures 

♦Facilities  for  secure  conferencing  -  with  easy  distribution  of  keys  and 
information 

♦Distributed  measurement,  monitoring  and  control 
Figure  2.2  Planned  MERCI  improvements  to  MICE  project  tools.  (MERCI,  1996) 
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The  expected  benefits  for  the  users  of  the  MERCI  applications  are  to  set  a 
standard  of  excellence  for  audio/visual  techniques  and  shared  whiteboard  in  tele-teaching, 
remote  consultation  of  doctors,  and  many  other  similar  disciplines.  Industrial 
organizations  are  also  expected  to  investigate  how  businesses  can  be  helped  by  the 
technology.  The  details  of  the  MERCI  project  can  be  found  at 
http: //WWW.  cs.  ucl.  ac.  uk/mice/merci/merci_desc.  html. 

2.  Anders  Klemets:  WWW  Media-on-Demand  System 

This  research  shows  that  supporting  the  playing  of  continuous  media  by  using 
external  programs  controlled  by  a  WWW  client  is  possible  (Klemets  1994).  Klemets’ 
paper  describes  the  design  and  implementation  of  a  unicast  "Media  on  Demand"  server 
that  uses  WWW  as  its  user  interface.  Offered  media  include  audio  and  video  recordings  of 
transmissions  on  the  Internet  Multicast  backbone  (MBone),  and  arbitrary  prerecorded 
audio  files  developed  during  the  MICE  project.  More  information  on  this  research  can  be 
foxmd  at:  http://www.itkth.se/~klemets/vatplay.html 

3.  Video  Mosaic  (Vosaic) 

This  research  addresses  the  problem  of  the  lack  of  architectures  that  encourage  the 
efficient  reuse  of  continuous  media,  such  as  video  and  audio  (Chen,  1995).  The 
researchers  propose  a  continuous  media  model  that  extends  the  architecture  of  the  WWW 
to  encompass  the  dynamic,  real-time  information  space  of  video  and  audio.  Their  new 
WWW  browser,  Vosaic,  short  for  Video  Mosaic,  incorporates  real-time  video  and  audio 
into  standard  hypertext  pages  that  are  displayed  in  place.  They  show  that  real-time  video 
and  audio  data  can  be  effectively  served  over  the  present  day  Internet  with  the  proper 
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transmission  protocol.  With  that,  they  have  developed  a  real  time  protocol  called  VDP 
that  specializes  in  handling  real-time  video  over  the  WWW.  VDP  reduces  inter-frame  jitter 
and  dynamically  adapts  to  the  client  CPU  load  and  network  congestion.  The  WWW 
server  dynamically  changes  transfer  protocols,  adapting  to  the  request  stream  and  the 
meta-information  in  requested  documents.  More  information  and  the  server  and  browser 
software  are  available  at  http://choices.cs.uiuc.edu/Vosaic/Vosaic.html. 

4.  Murat  Tamer:  Multicast  and  ATM  Network  Prerequisites  for 
Distance  Learning 

The  basic  problem  examined  in  this  thesis  is  how  the  Multicast  Backbone  and  the 
audio  and  video  tools  can  be  used  effectively  for  distance  education  (Tamer,  1996).  Here, 
the  key  to  effective  use  is  good  audio/video  quality  through  Internet  connections  with 
simple,  cost-effective  configurations.  The  focus  will  be  on  showing  schools  that  do  not 
have  great  financial  resources  how  to  enter  and  use  the  MBone  for  their  own  distance 
education  programs.  This  thesis  can  be  found  online  at: 
http://www.stl.nps.navy.mil/~iirg/tamer/thesis.html 

5.  Ridvan  Erdogan:  Implementation  of  Multicast  and  MBone  Over 
Frame  Relay  Networks 

This  is  a  thesis  that  shows  the  implementation  of  the  MBone  over  Monterey 
BayNet  for  educational  purposes  (Erdogan,  1996).  It  documents  the  need  for  and  the 
necessary  reconfiguration  of  Monterey  BayNet  sites  to  join  the  MBone.  It  shows  that 
MBone  over  Frame  Relay  networks  is  possible  and  that  the  current  MBone  technology 
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provides  satisfactory  performance  even  on  low-speed  (128  Kbps)  network  connections. 
This  thesis  can  be  found  online  at:  http:/AvmvMl.nps.ruxvy.mil/~iirg/erdogcm/thesis.html 

6.  Robert  Norris  and  Dave  West:  The  Digital  Library  Phenomenon: 
Opportunities  and  Implications  for  the  Naval  Service 

This  thesis  examines  the  emerging  field  of  work  encompassed  by  the  term  "Digital 
Library"  and  offers  a  plan  for  developing  a  Naval  Service  Digital  Library  (Norris,  West, 
1996).  Digital  resources  such  as  books,  magazines,  and  videos  are  all  part  of  this  plan. 
Archived  MBone  easily  fits  into  the  Digital  Library  concept  by  providing  easy  to  use, 
online  video  lectures  and  conferences  for  educational  purposes. 

7.  Wieland  Holfelder:  MBone  VCR  on  Demand  Service 

This  architecture  is  a  separate  project  that  planned  to  have  a  java  based  client  that 
has  access  to  an  MBone  VCR  server  over  a  CORBA  compliant  protocol  and  can  request 
recordings  and  playbacks  fi'om  the  server  (Holfelder,  1996).  The  server  will  and  announce 
playbacks  so  other  MBone-participants  have  access  to  them.  This  project  is  part  of 
continuing  research  into  the  use  of  MBone  VCR  by  Wieland  Holfelder  and  his  research 
group  at  the  University  of  Mannheim. 
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III.  PROBLEM  STATEMENT 

A.  INTRODUCTION 

This  chapter  gives  an  overview  of  what  pieces  of  the  distance  learning  puzzle  are 
missing  and  what  software  tools  can  be  used  to  fill  in  those  pieces.  The  chapter  goes  on 
to  discuss  where  MBone  archiving  fits  into  distance  learning  and  how  such  an  archive 
might  be  put  to  use  in  the  Naval  Service  and  the  Department  of  Defense  as  a  whole. 

B.  OVERVIEW 

Video  conferencing  is  already  widely  used  for  remote  participation  in  meeting  and 
classroom  settings.  With  many  commercial  products  available  for  conducting  video 
conferences  and  video  classes  over  the  Internet,  it  is  becoming  the  communication  medium 
of  choice  for  remote  participation.  The  MBone  is  one  of  the  most-used  systems  to  send 
and  receive  audio  and  video  over  the  Internet.  The  focus  of  this  thesis  is  to  show  how  to 
store  and  retrieve  multicast  sessions  using  the  real-time  audio  and  video  tools  available 
today,  all  in  an  economically  feasible  way. 

1.  Why  the  MBone? 

While  the  Multicast  Backbone  is  a  fairly  new  technology,  it  is  already  widely  used. 
The  MBone  is  well  suited  to  large,  distributed  presentations.  It  uses  network  bandwidth 
efficiently  and  allows  participants  to  join  and  leave  a  conference  easily.  Remote  seminar 
participants  can  receive  audio,  video  and,  in  some  cases,  whiteboard  information. 
Additionally,  interactive  audio  communication  is  possible  between  the  lecturers  and 
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remote  participants  (Rettinger,  1995).  Several  studies  have  shown  that  the  MBone  can 
support  real-time  classrooms,  thus  overcoming  the  distance  issues  in  distance  education 
and  remote  conferencing  (Tamer,  1996). 

2.  What  is  Missing? 

The  real-time  aspect  of  the  MBone  does  not  eliminate  any  of  the  time  constraints 
that  a  traditional  classroom  setting  imposes  on  its  students.  Considering  the  world-wide 
reach  of  the  MBone,  time  zone  differences  become  a  majc  otor  when  scheduling 
multicast  sessions.  A  student  on  another  continent  watching  an  event  in  the  United  States 
typically  must  forego  sleep  to  take  part  in  the  event.  The  main  question  then  becomes: 
Can  the  tools  available  today  provide  archived  MBone  sessions  that  can  be  watched  at  the 
users  convenience? 

C.  MULTICAST  BACKBONE  VIDEO  CONFERENCE 
RECORDER  (MBONE-VCR) 

The  recent  development  and  use  of  the  Real-time  Transport  Protocol  (RTPv2)  has 
greatly  increased  the  efficiency  of  real-time  conferencing  on  the  MBone.  As  this  protocol 
is  refined  further,  the  MBone  will  continue  to  expand  and  its  reach  across  the  globe, 
further  reducing  the  need  to  be  in  the  same  location  as  a  conference  or  class. 

The  MBone  VCR  was  developed  as  a  tool  to  allow  MBone  conference  members 
and  participants  to  record  content  for  later  playback  (Holfelder,  1995).  This  new  tool, 
which  is  compatible  with  the  real-time  transport  protocol  (RTPv2),  adds  more 
functionality  to  the  set  of  multicast  backbone  tools  and  can  aid  in  the  elimination  of 
restrictions  imposed  by  time  zone  differences  of  remote  conference  participants.  Chapter 
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rv  provides  a  closer  look  at  the  MBone  VCR.  Appendix  D  provides  the  instructions 
needed  for  basic  operations  of  the  MBone  VCR. 

D.  MBONE  ARCHIVING  AND  RETRIEVAL 

The  immediate  goal  of  this  project  was  to  store  the  Hamming  lecture  series  using 
the  MBone  VCR.  An  archive  of  those  files  is  being  created  to  allow  for  two  different 
types  of  retrieval:  ftp  and  real-time  streaming.  By  setting  up  this  archive  and  allowing  a 
remote  client  to  start  the  playback  of  any  of  the  recorded  sessions,  we  have  attempted  to 
remove  another  obstacle  to  the  acceptance  of  distance  learning  as  an  educational  tool. 

One  obstacle  that  has  to  be  overcome  for  the  on-demand  rebroadcast  of  MBone 
sessions  is  that  of  resource  allocation.  Since  the  MBone  has  an  agreed-upon  global 
bandwidth  of  only  500  Kbps,  the  number  of  individuals  allowed  to  play  back  a  session  at 
one  time  will  be  limited  by  existing  MBone  events.  In  order  to  avoid  the  abuse  of  the 
session  playback,  the  author  recommends  a  single  permanently  dedicated  global  MBone 
session  for  use  by  the  MBone  VCR.  The  retrieval  scripts  used  during  playback  will  check 
for  current  use  of  the  dedicated  session  and  only  start  transmitting  if  the  session  is  unused. 
The  scripts  will  further  limit  the  maximum  number  of  sessions  that  can  be  played  at  one 
time  to  one  global  session  (ttl=127)  and  two  local  campus  sessions  (ttl=15).  There  are  no 
restrictions  on  the  simultaneous  number  of  file  retrievals  via  ftp  (other  the  by  network 
congestion  and  user  patience.  Chapter  V  has  a  detailed  discussion  of  the  retrieval  methods 
offered  by  the  results  of  this  research. 
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E.  DOD  APPLICATIONS  OF  THE  MBONE  ARCHIVE 


The  applications  of  an  MBone  archive  go  hand-in-hand  with  those  used  every  day 
for  the  MBone  itself  However,  the  archive  adds  one  step  past  that  of  offering  a  class  or 
conference  to  anyone  in  any  place.  It  adds  the  flexibility  of  viewing  the  conference  at  any 
time.  The  number  of  individuals  involved  in  formal  education  and  number  of  conferences 
that  require  participants  to  travel  to  another  location  are  two  of  the  biggest  considerations 
when  contemplating  the  applicability  of  the  MBone  and  the  MBone  VCR. 

There  are  large  numbers  of  DoD  personnel  (both  trainees  and  instructors)  involved 
in  formal  courses  of  instruction  throughout  each  fiscal  year.  The  costs  involved  in  training 
personnel  through  a  formal  instructional  environment  include  travel  pay  and  allowances 
for  students  and  instructors  that  are  not  performing  regular  duties,  administrative  support 
of  students  and  instructors,  and  operation  and  maintenance  of  training  centers.  Many  of 
the  same  costs  apply  to  individuals  that  travel  to  participate  in  conferences  around  the 
globe. 

As  the  MBone  becomes  more  accepted  as  a  standard  for  distance  education  and 
remote  conferencing  and  the  inconvenience  of  viewing  classes  is  lessened,  large  savings 
can  be  achieved.  Personnel  will  be  able  to  participate  in  remote  training  classes  and 
conferences  either  at  the  time  of  the  original  broadcast  or  later  when  it  fits  into  their 
schedule.  Thus,  for  many  types  of  training  and  conferences,  and  with  pedagogical 
improvements  in  online  class  preparation  and  delivery,  we  expect  the  need  to  be  in  a 
particular  location  will  be  eliminated. 
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F.  SUMMARY 


The  software  tools  available  today  make  the  idea  of  a  usable  MBone  archive 
entirely  possible  and  economically  supportable.  This  chapter  briefly  discusses  where  the 
idea  of  MBone  archiving  comes  from,  and  how  it  applies  to  the  overall  goal  of  improving 
the  quality  of  distance  education.  This  chapter  also  shows  how  the  ideas  discussed  in  this 
thesis  have  possible  far-reaching  implications,  not  only  in  the  Naval  Service  but 
throughout  the  entire  Department  of  Defense  and  academic  community. 
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IV.  DIGITAL  TRANSPORT  ISSUES 


A.  INTRODUCTION 

This  chapter  briefly  outlines  the  reasons  leading  to  the  formation  of  the  AVT  WG 
and  how  the  Real-time  Transport  Protocol  (RTPv2)  attempts  to  solve  the  bandwidth 
issues  related  to  transporting  audio  and  video  over  the  Internet.  It  also  reviews  the  most 
commonly  used  MBone  tools  and  describes  the  features  of  the  MBone  VCR. 

B.  BACKGROUND 

Due  to  bandwidth  constraints,  real-time  audio  and  video  over  the  Internet  is  a 
difficult  proposition.  At  the  same  time,  teaching  a  class  or  holding  a  meeting  over  a 
network  requires  real-time  interactivity  and  adequate  picture  quality.  Private  networks 
accomplish  this  by  using  proprietary  VTC  protocols  and  high-speed  dedicated  links.  The 
Internet  is  a  media  shared  by  millions  of  users  and  it  cannot  easily  support  the  high 
bandwidth  required  for  real-time  audio  and  video.  To  solve  this  problem,  many 
commercial  products  made  for  relative  low-bandwidth  video  conferencing  over  the 
Internet  have  recently  become  available.  Even  with  these  products,  the  limited  bandwidth 
of  the  Internet  cannot  support  the  entire  potential  demand  for  real-time  service.  There  is  a 
real  possibility  of  severe  network  congestion  problems  caused  by  indisciminate  use  of 
poorly  designed  real-time  tools.  Thus  the  Internet  Engineering  Task  Force  (IETF),  the 
standardization  body  of  the  Internet,  saw  a  need  to  establish  a  standard  protocol  for  real¬ 
time  data  transport. 


21 


The  Audio- Video  Transport  Working  Group  (AVT  WG)  within  the  BETF  has  been 
charged  with  developing  a  protocol  that  facilitates  the  transport  of  digitized  real-time  data 
(such  as  interactive  voice  and  video)  over  packet-switched  networks  (i.e.  the  Internet). 
Through  their  efforts,  the  use  of  live  audio  and  video  across  networks  continues  to 
become  more  and  more  efficient.  In  January  of  1996  the  AVT  WG  published  a  Request 
for  Comments  detailing  a  real-time  transport  protocol  (RTPv2)  that  is  widely  used  in  the 
software  tools  available  for  the  MBone. 

C.  REAL-TIME  TRANSPORT  PROTOCOL  VERSION  2  (RTPv2) 

The  Real-time  Transport  Protocol  (RTPv2)  developed  by  the  AVT  WG  is  intended 
to  provide  standardization  of  streaming  packet  header  formats  (IETF  RFC  1889,  1996). 
RTPv2  is  intended  to  support  improved  end-to-end  network  transport  functionality 
suitable  for  applications  transmitting  real-time  streams  (such  as  audio,  video,  or  simulation 
data)  over  multicast  or  unicast  network  links.  However,  RTP  does  not  provide  a 
guaranteed  quality  of  service  (QoS).  Therefore,  a  separate  Real-time  Transport  Control 
Protocol  (RTCP)  provides  the  augmentation  needed  to  monitor  the  delivery  of  the  data). 
Another  issue  not  addressed  by  RTP  is  that  of  resource  reservation.  RTCP  is  sufficient  to 
meet  quality  of  service  QoS  goals  during  some  sessions,  but  it  will  not  necessarily  provide 
support  to  all  of  the  communication  control  requirements  of  any  one  application.  Instead, 
if  desired,  RTP/RTCP  relies  on  resource  reservation  protocols  for  QoS  support,  which  go 
beyond  the  scope  of  this  thesis.  (IETF  RFC  1889,  1996) 

RTP  and  RTCP  are  designed  to  be  independent  of  the  transport  and  network 
protocols  used  in  a  system.  Therefore,  as  long  as  the  underlying  network  supports 
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multicast  distribution,  RTP  supports  the  data  transfer.  The  efforts  to  make  RTP  transport 
and  network  independent  will  allow  its  use  over  many  protocols.  RTP  is  even  currently  in 
experimental  use  directly  over  Asynchronous  Transfer  Mode  Adaptaion  Layer  5  (AAL  5). 

Analog  audio  and  video  sources  must  be  digitally  encoded  before  transmitting 
them  using  RTP.  There  is  a  set  of  default  payload  types  that  are  mapped  to  particular 
audio  and  video  encodings.  The  set  up  of  the  protocol  allows  sources  to  emit  only  a 
single  RTP  payload  type.  Currently  defined  payload  types  carry  either  audio  or  video. 
This  allows  a  participant  to  separate  the  reception  of  audio  or  video  if  the  network 
bandwidth  cannot  handle  both.  Figure  4. 1  shows  the  current  encodings  that  are  mapped 
to  payload  types. 


Audio  Payloads 

Video  Payloads 

1016  (CELP) 

LPC 

CeUB 

G.721 

MPA 

JPEG 

G.722 

PCMA 

H.261 

GSM 

PCMU 

MPV 

L8 

VDVI 

MP2T 

L16 

nv 

Figure  4. 1  AudioA^ideo  Encodings  Mapped  to  RTPv2  Payload  Types  (IETF  RFC 


1890,1996) 


Additional  payload  types  can  be  defined  dynamically  with  the  use  of  conference 
control  applications  that  are  separate  firom  RTP  and  RTCP.  Multiple  RTP  sessions  can  be 
used  in  parallel  to  send  multiple  media  types.  Timing  information  carried  in  the  RTCP 
packets  is  used  for  synchronization  (IETF  RFC  1890,  1996).  This  capability  is  used  by 
MBone  VCR  to  synchronize  separately  stored  audio-video  streams. 
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D.  MULTICAST  BACKBONE  (MBONE)  SOFTWARE  TOOLS 

The  following  sections  describe  some  of  the  most  popular,  free  MBone 
applications  available  for  use  on  almost  any  computing  platform.  To  make  use  of  the 
conferencing  tools,  a  LAN  must  support  IP  Multicast  and  (ideally)  be  connected  to  the 
MBone. 

1.  Session  Directory  (sdr) 

The  session  directory  (set)  tool  is  used  to  advertise  and  manage  the  individual 
MBone  sessions.  It  lists  the  available  sessions,  is  used  to  create  new  sessions,  and 
provides  detailed  additional  information  on  each  session  that  is  listed.  The  session 
directory  tool  also  provides  the  functionality  to  launch  the  appropriate  viewing  tools 
needed  to  watch  (and  listen  to)  any  session  listed.  The  latest  versions  of  set  have  a  record 
button  that  is  supported  by  a  separate  shell  script  program  (recorei  session)  facilitating 
launch  of  the  MBone  recording  tool,  MBone  VCR. 

An  earlier  independently  developed  session  directory  (sd)  tool  is  also  available 
(Wood,  1996).  Currently,  sdr  use  and  functionality  is  much  broader  that  that  o^sd. 

2.  Video  Conference  (vie)  Tool 

The  vie  video  tool,  developed  at  the  Lawrence  Berkeley  National  Laboratory 
(LBNL)  is  used  to  transmit  and  receive  video  over  the  MBone.  It  is  based  on  RTPv2  and 
can  be  used  in  a  point-to-point  environment.  However,  it  is  primarily  intended  for  use  in 
multicast/multiparty  conferencing  environments,  vie  is  backward  compatible  with  RTPvl 
and  can  interoperate  with  both  nv  (v3.3)  (Frederick,  1996)  and  ivs  (v3.3)  (Turletti,  1996), 
other  video  tools  developed  at  separate  labs.  (McCanne,  Jacobson,  1996) 
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vie  includes  the  H.261  video  compression  algorithm  which  can  achieve  frame  rates 
2-4  times  better  than  that  of  previous  video  tools.  This  is  accomplished  using  a 
sophisticated  compression  technique  that  replenishes  only  the  blocks  of  the  picture  that 
change.  Using  cues  from  the  audio  tool,  vie  also  has  the  ability  to  switch  the  active 
viewing  window  among  multiple  simultaneous  video  sources  to  whichever  source  is 
speaking.  (McCanne,  Jacobson,  1996) 

3.  Visual  Audio  Tool  (vat) 

The  visual  audio  tool  (yat),  also  developed  at  LBNL,  is  a  real-time  audio 
application.  Like  vie,  it  is  based  on  RTPv2  and  can  be  used  in  a  point-to-point 
environment,  vat  is  also  primarily  intended  for  multicast/multiparty  conferencing 
environments.  (Jacobson,  McCanne,  1996) 

4.  Robust  Audio  Tool  (rat) 

rat  is  an  RTPv2-compliant  MBone  audio  tool,  available  for  SunOS,  Solaris,  IRIX 
and  Windows-95  platforms  (UCL,  1996).  It  is  developed  by  the  Department  of  Computer 
Science,  University  College  London  (UCL)  in  the  United  Kingdom,  rat  can  interoperate 
with  vat  v.4.0  and  has  a  packet-loss  protection  mode  using  redundant  encodings  (i.e. 
forward  error  correction  -  FEC)  which  provides  enhanced  performance  during  conditions 
of  packet  loss,  rat  is  similar  to  existing  audio  tools  (such  as  vat)  but  offers  the  extra 
functionality  listed  in  Figure  4.2. 

We  have  found  that  the  redundancy  feature  is  very  powerful  and  provides 
significant  improvement  in  audio  quality  even  in  conditions  of  10%  packet  loss.  The 
addition  of  FEC  on  a  per-packet  basis  is  offset  by  rat  slightly  reducing  the  default 
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♦Redundancy  (packet  loss  protection)  using  forward  error  correction 
(FEC)  encodings 

♦Improved  statistics 

♦Voice  /  picture  synchronization  option 

♦Improved  hands-free  performance  option 

Figure  4.2  Extra  Functionality  Offered  by  rat  (UCL,  1996) 

sampling  rate  so  that  total  bandwidth  and  packets-per-second  rate  is  unchanged  (Handley, 
1996).  No  redundancy  compatibility  is  currently  planned  with  vat  due  to  different  internal 
buffering  schemes  used  in  each  tool. 

5.  Shared  Whiteboard  (yvh) 

The  shared  whiteboard  application  can  be  used  as  a  shared  drawing  surface  which 
can  also  import,  export,  and  view  both  plain  text  and  Postscript  files  (Jacobson, 

McCanne,  1996).  wb  facilitates  non-audio  interaction  and  can  be  used  to  reliably 
distribute  moderately  large  postscript  copies  of  a  speaker’s  slides.  Viewers  can  easily 
watch  and  listen  to  the  speaker  using  video  and  audio  while  simultaneously  viewing  the 
slides  and  annotating  questions  using  wh. 

E.  MULTICAST  BACKBONE  VIDEO  CONFERENCE 
RECORDER  (MBONE-VCR) 

This  application  is  designed  and  developed  for  use  on  the  Internet's  Multicast 
Backbone  (MBone)  (Holfelder,  1995).  It  reads  cached  session  advertisement  data  from 
the  active  session  directory  tool  {sd  or  sdr)  that  allows  the  importing  of  MBone  sessions 
directly  to  the  VCR.  A  graphical  user  interface  (GUI)  is  used  to  control  recording  and 
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playback  of  sessions  sent  over  the  MBone.  The  VCR  stores  these  sessions  by 
synchronizing  different  media  streams  based  on  information  provided  by  RTP.  It  also 
permits  indexing  and  random  access  within  recorded  sessions.  A  command  language 
enables  user-independent  MBone  VCR  programming  features,  e.g.  to  schedule  recordings 
or  playbacks  at  arbitrary  times.  RTPv2  information  is  used  during  the  playback  of 
recorded  sessions.  The  MBone  VCR  sends  the  audio/video  data  streams  out  on  a 
multicast  network  address/port  combinations,  recovering  the  original  tinung  of  all  the 
media  streams  included  in  a  session  and  advertising  the  same  encoding  protocols  used  by 
the  original  applications  from  which  the  data  was  recorded  (Holfelder,  1995).  Once 
playback  has  started,  the  user  views  the  session  with  the  same  tools  (e.g  vie  and  rat  or  vat) 
used  in  the  original  multicast  session  that  was  recorded. 

Users  of  the  MBone  VCR  are  provided  with  a  GUI  that  looks  like  the  control 
panel  of  a  standard  video  cassette  recorder.  The  ease  of  use  provided  by  this  interface 
enables  even  first-time  users  to  operate  the  basic  MBone  VCR  fimetions.  Another 
important  feature  of  the  MBone  VCR  is  that  it  allows  the  alteration  of  the  scope  (i.e.  ttl) 
of  the  session  playback.  The  user  is  thus  able  to  determine  whether  the  playback  is 
intended  for  a  smaller  or  larger  (e.g.  local  ttl=15  or  global  ttl=127)  audience  than  the 
original  multicast.  Appendix  D  provides  instructions  on  the  operation  and  use  of  the 
MBone  VCR  tool. 

These  features  of  the  MBone  VCR  add  significant  new  functionality  to  the 
current  MBone  application  software  suite.  Through  the  use  of  the  MBone  VCR,  three 
important  benefits  are  achieved;  (1)  independence  from  application-specific  details,  (2) 
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use  of  already  invented  and  implemented  software  tools  for  playback  and  (3)  off-line 
teleconferencing  support,  since  sessions  can  be  recorded  and  sent  out  at  a  later  time 
reaching  audiences  in  various  time  zones.  (Holfelfer,  1995) 

F.  SUMMARY 

This  chapter  summarizes  the  issues  relating  to  problems  transporting  audio  and 
video  from  one  site  to  another.  It  discusses  how  the  bandwidth  problem  lead  to  the 
formation  of  the  Audio- Video  Transport  Working  Group  (AVT  WG)  and  provides  a 
discussion  of  the  Real-time  Transport  Protocol  (RTPv2)  the  group  has  developed.  Next, 
the  chapter  goes  on  to  review  the  features  of  the  most-often-used  Multicast  Backbone 
tools.  This  is  followed  by  a  discussion  of  the  Muticast  Backbone  Video  Conference 
Recorder  (MBone  VCR),  its  features  and  how  it  can  add  to  the  usefulness  of  the  MBone 
as  an  educational  tool.  Chapter  VI  details  the  experimental  results  from  the  use  of  these 
tools  and  Appendix  C  provides  instructions  for  the  basic  use  of  the  MBone  VCR. 
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V.  ARCHIVING  /  STORAGE  /  ACCESS  ISSUES 


A.  INTRODUCTION 

This  chapter  gives  the  background  of  the  research  documented  in  this  thesis  and 
addresses  the  issues  that  relate  to  building  an  MBone  archive.  It  further  describes  the  two 
types  of  access  planned  for  the  archive.  Finally  it  examines  the  bandwidth  issues  related  to 
transmitting  sessions  from  the  recorded  archive. 

B.  BACKGROUND 

Originally  this  research  focused  on  other  digital  encoding  schemes  such  as  MPEG 
1,  MPEG  2,  and  MJPEG.  Using  these  methods  gave  file  sizes  on  the  order  of  gigabytes 
for  a  feature  length  film  (Klemets,  1994).  Storing  a  reasonable  collection  of  classes  or 
lectures  would  require  massive  amounts  of  storage  on  expensive  disks  or  in  a  tertiary 
storage  system.  Our  such  storage  system  is  the  Data  Migration  Facility  (DMF)  (also 
known  as  the  “tape  bam”)  at  NPS.  Due  to  the  expense  involved  with  using  huge 
magnetic  disks  or  off-site  storage  facilities,  the  DMF  seemed  to  be  the  most  economical 
alternative.  Except  for  1-2  minute  delays  during  the  mechanical  movement  of  tapes  during 
initial  access,  the  retrieval  process  would  require  no  special  actions  by  remote  users  of  the 
system. 

The  cost  of  DMF  tapes  (about  $25  per  5  GB  tape)  reasonably  satisfies  the 
economical  side  of  the  problem.  However,  for  sites  that  do  not  have  mechanical  tape 
stations  this  was  not  a  feasible  solution.  Therefore,  due  to  the  difficulties  managing  file 
sizes  created  by  these  compression  techniques,  our  focus  turned  to  the  use  of  the  MBone 
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recording  tools  which  simply  save  the  packets  of  data  that  travel  across  the  network. 
Here,  the  file  sizes  depend  solely  on  the  amount  of  bandwidth  used  in  the  transmission  of 
each  session.  Lectures  can  be  practically  stored  on  LAN  storage  disks.  Numerous  NPS 
lectures  comprising  a  video  archive  might  still  utilize  the  NPS  DMF  capabilities  to 
augment  ordinary  server  storage  capacity. 

C.  BUILDING  AN  ARCHIVE 

1.  Recording 

The  video  for  this  system  is  recorded  using  the  MBone  and  the  MBone  VCR 
discussed  in  Chapter  IV.  The  three  simple  steps  involved  in  digitally  recording  an 
audio/video  lecture  (that  already  exists  on  video  tape)  are  listed  in  Figure  5.1. 

1 .  Create  an  MBone  session  with  a  ttl  of  1 5  or  less  so  that  it  does  not  go 
beyond  the  local  network. 

2.  Begin  playing  the  video  tape  to  be  recorded  as  the  input  to  the  MBone 
session. 

3.  Record  the  session  on  a  separate  workstation  using  the  MBone  VCR. 

Figure  5. 1  Simplified  steps  for  digitally  recording  a  video  tape  session  using  the 
MBone  VCR 

The  session  files  are  deposited  directly  to  proper  storage  area  and  are  ready  to  be  played 
after  competion.  Appendix  C  provides  a  detailed  explanation  of  the  basic  functions  of  the 
MBone  VCR.  Copyright  permissions  are  not  necessary  for  our  current  efforts  since  all 
sessions  are  in  the  public  domain.  This  remains  an  important  consideration  in  future  work. 
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2.  Storage  Space 

When  considering  the  storage  issues  that  apply  to  the  MBone  archive,  the  author 
had  two  main  areas  of  concern.  The  most  prominent  question  was  how  much  digital 
storage  a  large  archive  might  use.  The  second  question  was  what  type  of  storage  media 
best  supports  web-based  access  to  the  archive. 

The  amount  of  digital  storage  space  required  for  a  recording  is  dependent  on  the 
amount  of  bandwidth  used  during  the  original  session  broadcast.  The  MBone  has  a 
maximum  global  capacity  of  500  Kbps  (at  the  time  of  this  writing),  but  the  standard 
transmission  levels  used  for  most  sessions  is  128  Kbps  for  video  and  64  Kbps  for  audio. 
We  assume  that  recording  each  session  once  (at  a  frame  rate  suitable  for  either  local  or 
global  playback)  is  a  practical  solution.  Using  these  numbers  we  arrive  at  a  transmission 
that  uses  approximately  200  Kbps  (a  conservatively  high  estimate).  Since  the  ultimate 
goal  is  to  use  this  technology  for  a  lecture-style  digital  classroom  we  will  assume  that  each 
session  will  be  a  50-minute  lecture.  Estimated  digital  storage  requirements  are  shown  in 
Figure  5.2. 

200  Kbps  stream  *  8  bits/Byte  =  25  KBps  per  second 

25  KBps  *  60  seconds/minute  =  1500  KB/minute 

1500  KB/minute  =1.5  MB/minute 

1.5  MB/minute  *  50  minutes/lecture  =  75  MB/lecture,  or 

1.5  MB/minute  *  60  minutes/hour  =  90  MB/hour 
Figure  5.2  Estimated  digital  storage  requirements. 
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Therefore,  with  a  50  minute  lecture,  we  expect  to  use  75  MB5^es  of  space.  Using  these 
figures  and  assuming  that  each  academic-quarter  course  will  have  about  30  lectures,  a 
typical  course  might  use  an  approximate  total  of  2.25  GB  of  storage  space.  These 
numbers  are  significantly  smaller  than  the  estimates  established  at  the  beginning  of  this 
research  using  MPEG  compression  and  previous  MBone  tools.  Recent  improvements  in 
the  compression  techmques  used  in  the  audio  and  video  tools  have  further  decreased  the 
required  bandwidth  while  at  the  same  time  improving  frame  rate  and  image  resolution  by 
factors  of  2-4  times.  This  translates  into  less  space  required  to  archive  the  desired  MBone 
sessions  with  acceptable  audio/video  quality.  Experimental  results  reported  in  Chapter  VI 
indicate  that  a  30-lecture  archive  may  require  just  under  2  GB. 

The  type  of  storage  media  to  be  used  in  this  system  was  the  second  issue  to  be 
addressed.  Several  options  were  examined,  including  the  use  of  the  DMF  at  NPS, 
CD-ROM  or  standard  magnetic  disk  storage.  This  problem  has  been  greatly  simplified  by 
the  increasing  efficiency  of  the  compression  techmques  used  by  the  MBone  tools.  Since 
the  compression  of  the  video  and  audio  has  provided  for  large  reductions  in  file  sizes  and 
brings  them  down  to  manageable  levels,  individuals  might  even  be  able  to  start  recording 
and  watching  short  sessions  on  their  own  smaller  typical  LANs. 

In  this  project  at  NPS  we  purchased  a  9  GB  hard  drive  for  primary  storage  and 
investigated  using  the  DMF  as  backup  storage  space.  CD-ROM  has  a  capacity  of  650 
MB,  which  is  another  possibility  for  storing  the  MBone  sessions.  Using  a  CD-ROM  drive 
with  a  data  transfer  capacity  of  up  to  600  KBps  will  allow  distribution  of  the  recorded 
lecture  series  or  conferences  to  those  hosts  or  networks  that  have  slow  outside 
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connections.  CD-ROM  may  also  be  useful  if  the  MBone  VCR  application  is  ported  to  the 
realm  of  the  PC.  Then  even  individuals  with  no  network  connection  at  all  will  be  able  to 
benefit  from  the  content  of  the  MBone.  This  is  a  promising  area  for  future  work. 

In  the  end,  the  issue  of  what  type  of  storage  media  to  use  must  primarily  be  based 
on  the  type  that  is  available  and  the  purpose  of  the  recordings  at  the  site  that  is 
establishing  an  archive.  Our  site  uses  the  9  GB  hard  drive  accessed  via  a  standard  UNIX- 
based  Network  File  System  (NFS)  as  primary  store  and  the  DMF  as  a  backup  facility. 

3.  Ffle  Naming  Conventions 

MBone  VCR  automatically  generates  a  set  of  control  files  for  each  session 
recording.  The  session  is  specified  in  a  session  file  that  is  named  according  to  the  session 
name  and  appended  with  a  .vcr  extension.  The  session_name .  vcr  file  contains  a 
description  of  the  session,  the  included  media  and  all  of  the  media  parameters  in  plain 
ASCII  format.  Along  with  the  session  file,  VCR  generates  two  other  files  per  media  in  the 
same  directory.  The  filenames  for  these  files  are  also  automatically  generated  out  of  the 
session  filename,  the  media  protocol  and  the  media  number.  The  first  is  a  data  file  that 
ends  in  .rec  (e.g.  session_name .  rec)  that  contains  the  raw  data  placed  into  the  file  as 
it  is  received  from  the  network.  The  second  is  an  index  file  that  ends  in  .idx  (e.g. 
session_name .  idx)  that  contains  one  fixed-length  header  per  data  packet.  This  RTP 
header  holds  a  mapped  time  stamp  generated  from  information  of  the  data  time  stamp, 
index  information,  channel  information  (e.g.  data/session  port)  and  an  offset  to  the 
corresponding  data  packet  in  the  session_name .  rec  file  (Holfelder,  1995). 
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For  example,  if  a  user  records  a  session  consisting  of  one  RTF  media  (such  as 

audio)  and  has  a  session  name  of  “test”  the  list  of  files  will  be: 

test . vcr 
test_rtp_l . idx 
test_rtp_l . rec 

Recording  a  session  using  a  second  RTF  media  (such  as  video)  adds  the  following  files: 

test_rtp_2 . idx 
test_rtp_2 . rec 

The  MBone  VCR  appends  _rtp_l  for  the  first  media  and  _rtp_2  for  the  second  media. 
This  simply  to  identifies  the  two  types  of  media  (e.g.  audio_rtp_l  or  video_rtp_2).  It  has 
nothing  to  do  with  the  version  of  the  RTF  that  is  used.  All  media  are  recorded  using 
RTFv2. 

The  author  has  chosen  a  simple  session  file  naming  convention  that  indicates  the 

content  and  date  of  each  lecture.  An  example  set  of  all  data  and  index  file  names  that 

goes  with  a  single  Hamming  Lecture  session  using  audio  and  video  is  as  follows. 

Hainiaing_l_Apr95  .vcr 
Hainming_l_Apr95_rtp_l .  idx 
Hainming_l_Apr95_rtp_l .  rec 
Haitiming_l_Apr95_rtp_2 .  idx 
Hainming_l_Apr95_rtp_2 .  rec 

This  set  of  files  is  for  the  first  lecture  in  the  series  of  Hamming  lectures.  Care  has  been 
taken  to  ensure  that  when  the  sessions  involve  a  series  of  lectures  or  conference  meetings 
that  the  files  are  listed  in  the  proper  order.  Here,  the  reader  can  see  that  the  first  lecture  in 
the  series  will  be  listed  before  the  second  (Hamming_2_Apr95)  all  of  the  way  through  the 
30th  lecture. 
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The  limitation  of  file  name  lengths  that  is  imposed  by  DOS  PCS  was  not  taken  into 
consideration  with  this  naming  scheme  since  (up  to  this  point  in  time)  the  VCR  is  not 
supported  by  any  PC  systems.  We  expect  that  long  self-descriptive  filenames  under  UNIX 
can  be  mapped  to  8-character  filenames  for  DOS  or  CD-ROM  storage  with  minimal 
difficulty. 

D.  ACCESS  METHODS 

Making  the  playback  simple  enough  for  MBone  beginners  is  one  of  the  top  goals 
of  this  project.  At  this  time  the  easiest  technology  to  use  is  the  World  Wide  Web.  The 
web  browsers  available  today  have  a  highly  simplified  point  and  click  interface,  easily 
mastered  by  millions  of  users,  and  most  web  servers  support  common  gateway  interface 
(CGI)  programming  (Herrmann,  1996).  Using  the  MBone  VCR,  CGI  scripting,  and  file 
transfer  protocol  (ftp)  the  author  has  implemented  two  different  methods  for  retrieving  the 
recorded  MBone  sessions. 

1.  Web  Page  /  CGI 

This  method  uses  a  CGI  script  written  in  the  perl  language  (available  in  Appendix 
B)  that  identifies  the  files  to  be  played  from  a  web  page  selection  made  by  the  user.  The 
script  then  launches  MBone  VCR.  The  script  response  that  the  user  sees  provides 
directions  that  the  user  needs  to  properly  launch  the  MBone  tools  on  a  local  workstation. 
This  is  similar  to  the  approach  demonstrated  by  Anders  Klemets  in  the  Media  on  Demand 
System  for  WWW  (Klemets,  1994).  The  uniform  resource  locator  (URL)  for  this  page  is 
http://wwwAt.kth.se/~klernets/vatplciy.html 
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This  method  of  direct  retrieval  via  the  MBone  will  most  likely  be  used  by  larger 
sites  that  have  high-speed  LANs  (e.g.  Ethernet  or  better)  and  high-speed  connections  (e.g. 
T-1, 1 .5  Mbps)  to  the  Internet.  The  bandwidth  that  is  required  here  is  the  same  as  that 
which  is  required  to  watch  MBone  sessions  live. 

Through  the  use  of  the  web  page  the  user  will  have  several  choices  for  playback 
provided  by  the  CGI  script  combo-form.  User  choices  include  what  session  is  to  be 
played,  what  media  the  user  wants  to  receive  (i.e.  audio  and  video,  only  audio,  or  only 
video),  what  time-to-live  (ttl)  is  to  be  used  (default  is  local  ttl=15),  and  what  time  the 
playback  is  to  start  (the  default  is  immediately).  Once  the  form  is  submitted  by  the  user 
the  server  responds  with  a  message  that  confirms  the  user’s  choices  and  tells  the  user 
what  needs  to  be  entered  on  the  local  host’s  command  line  to  watch  the  plajdng  session. 
Since  the  total  MBone  bandwidth  is  limited  to  500  Kbps,  only  one  user  at  a  time  will  be 
allowed  to  play  a  global  session.  Users  that  come  in  after  the  session  has  started  will  be 
given  a  message  similar  to  the  first  telling  them  what  session  is  currently  playing  and  what 
tools  to  launch  in  order  to  watch  it.  Important  future  work  includes  automating  the  local 
launch  of  the  MBone  tools,  perhaps  by  using  Java  applets. 

2.  FTP 

The  ftp  method  uses  a  simple  web  page  generated  from  a  listing  of  compressed  .tar 
files  that  include  all  files  applicable  to  a  particular  session  recording.  The  user  selects  a 
compressed  .tar  file  and  transfers  that  file  to  his  location.  Once  the  file  has  been 
transferred,  the  user  uncompresses  and  expands  the  set  of  files  and  manually  launches  the 
MBone  VCR.  The  user  then  chooses  the  set  of  files  to  be  played  by  the  VCR  and  watches 


the  session  on  his  local  network.  In  this  case  the  scope  of  the  new  multicast  session  does 
not  need  to  go  beyond  the  user’s  local  network. 

This  method  wUl  be  used  most  often  when  the  receiving  network  does  not  have  an 
outside  connection  with  suitable  bandwidth  to  receive  a  live  MBone  transmission,  but  can 
support  the  tools  either  on  a  single  workstation  or  on  the  local  network.  Smaller 
commands  and  geographically  remote  sites  that  do  not  have  good  telephone  company 
support  are  perfect  candidates  for  using  this  method.  In  this  way,  sites  that  cannot  view 
multicast  MBone  content  will  now  be  able  to  see  what  they  have  been  missing. 

Figure  5.3  shows  the  UNIX  command  line  entries  required  to  tar/compress  the 
MBone  VCR  session  files.  Once  the  files  are  compressed  they  can  be  transferred  to  the 
archive  storage  facility  for  retrieval.  Figure  5.4  shows  the  entries  that  uncompress  and 
untar  the  files. 


Command 

tar  -cvf  session_title . tar 
session_  title. vcr 

tar  --rvf  session_title .  tar 

session_  title_rtp_l .idx 

tar  -rvf  session_title. tar 
session_title_rtp_l . rec 

tar  -rvf  session_title . tar 
session_title_rtp_2 . idx 

tar  -rvf  session_title. tar 
session_title__rtp_2 .  rec 

gzip  session_title . tar 


Description 

Creates  the  .tar  file  and  adds  the 
.vcr  file  to  it 

Adds  first  .idx  file  to  .tar 
file 

Adds  first  .rec  file  to  .tar  file 


Adds  second  .idx  file  to  .tar  file 


Adds  second  .rec  file  to  .tar  file 


Compresses  the  tar  file 
Figure  5.3  UNIX  command  line  entries  to  tar/gzip  session  files 
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Command 

Description 

gunzip  session_title. tar. gz 

Uncompresses  the  .tar  file 

tar  -xvf  session__title. tar 

Extracts  the  five  files  from  the 

.tar  file 

Figure  5.4  UNIX  command  line  entries  to  untar/gunzip  session  files 


E.  BANDWIDTH  REQUIREMENTS 

The  definition  of  bandwidth  is  the  capacity  of  a  communications  connection  to 
transmit  data.  Bandwidth  can  be  dedicated  to  one  user  or  shared  among  many  users.  In 
the  case  of  the  MBone,  the  maximum  agreed  bandwidth  shared  globally  is  500  Kbps.  This 
limitation  is  on  a  global  scale,  so  this  only  limits  the  number  of  active  world-wide  sessions 
that  can  be  played  at  any  one  time.  Since  the  standard  transmission  levels  of  any  MBone 
session  are  decreasing  due  to  improved  compression  in  the  tools,  several  sessions 
(typically  2  or  3)  can  coexist  using  the  limited  capacity. 

This  MBone-on-demand  system  is  set  up  to  play  only  one  global  session  at  a  time 
so  as  not  to  usurp  the  bandwidth  available  for  the  entire  MBone  community. 

Nevertheless,  the  number  of  local  broadcasts  is  limited  only  by  the  campus  LAN/backbone 
capacity.  At  NFS,  we  will  limit  that  to  two  concurrent  local  MBone  VCR  playback 
sessions.  Two  session  (400Kbps)  easily  fits  into  the  10  Mbps  Ethemet/100  Mbps  FDDI 
MBone  on  campus.  Finally,  the  number  of  simultaneous  ftp  transfers  is  not  constrained. 
The  actual  duration  of  those  transfers  depends  on  the  current  load  on  the  network. 
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F.  SUMMARY 


This  chapter  reviews  the  reasons  behind  the  focus  of  this  thesis.  It  goes  on  to 
outline  the  major  issues  pertinent  to  building  an  MBone  archive  and  describes  the  methods 
used  to  access  such  an  archive.  General  considerations  regarding  bandwidth  used  for 
transmitting  the  contents  of  the  recorded  MBone  sessions  are  presented.  Appendix  B 
shows  the  html  and  cgi  scripts  used  to  establish  Web  access  to  the  video  archive. 
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VI.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

This  chapter  provides  an  overview  of  the  experiments  that  were  performed  using 
version  l.SaOl  of  the  MBone  VCR.  It  then  details  the  results  of  each  attempt  to  use  the 
MBone  VCR  to  record  and  play  MBone  sessions.  This  is  followed  by  an  examination  of 
the  file  sizes  produced  by  recording  conference  session  and  the  results  of  experiments 
performing  each  of  the  two  retrieval  methods  discussed  in  chapter  V. 

B.  OVERVIEW 

The  testing  described  in  this  chapter  is  accomplished  using  the  MBone  VCR’s 
graphical  user  interface  (GUI)  and  the  MBone  tools  sdr,  vat  and  vie.  RTPv2,  developed 
by  the  IETF  AVT  WG,  is  the  protocol  used  by  the  transmitting  tools  and  recorded  by  the 
MBone  VCR.  A  software  bug  prevented  our  recording  using  rat  with  PCM  redundancy 
enabled.  This  will  be  our  preferred  audio  encoding  due  to  significantly  improved  audio 
performance  in  the  presence  of  network  congestion  and  packet  loss. 

Since  the  MBone  tools  are  used  regularly  and  have  been  proven  to  work,  the 
testing  focuses  on  the  addition  of  the  MBone  VCR  to  MBone  process.  The  author  had 
six  goals  (listed  in  Figure  6.1)  when  conducting  the  MBone  VCR  experiments,  all  intended 
to  evaluate  the  effectiveness  of  this  new  combination  of  software  tools. 

Each  initial  recording  experiment  consisted  of  loading  the  audio  and  video  session 
into  the  VCR  interface  and  recording  for  five  minutes. 
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♦Broadcasting  and  recording  on  the  same  workstation 
♦Recording  between  workstations 
♦Recording  transmissions  from  another  network 
♦Playing  and  watching  on  the  same  workstation 
♦Playing  between  workstations 
♦Playing  across  networks 

Figure  6. 1  Experimental  Test  Goals 

The  binary  distributions  for  all  of  the  software  application  tools  {sdr,  vie,  vat,  rat, 
MBone  VCR)  are  each  downloaded  from  one  of  the  many  ftp  sites  that  provide  the 
MBone  tools.  The  Multimedia  Conferencing  Applications  Archive,  supported  by  UK 
MICE  National  Support  Center  (Wood,  1996)  is  the  most  comprehensive  of  those  sites. 
Appendix  C  gives  the  instructions  for  downloading  and  installing  the  proper  tools  as  well 
as  operating  the  MBone  VCR. 

C.  RECORDING  A  SESSION 

The  first  step  in  our  testing  the  effectiveness  of  the  MBone  VCR  is  recording  an 
MBone  session.  If  the  MBone  session  is  broadcast  using  sd  the  MBone  VCR  can  load  it 
directly.  If  sdr  is  used,  a  corresponding  new  session  must  be  created  using  the  “create 
new  session”  function  under  the  VCR  session  menu.  The  multicast  addresses  and  port 
numbers  (advertised  by  sdr)  must  be  entered  manually  (this  feature  will  be  added  in  a 
future  VCR  version).  Once  the  session  is  loaded  into  the  VCR,  a  deposit  directory  is 
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selected  and  recording  has  been  enabled  on  the  user’s  workstation,  recording  begins  by 
simply  clicking  on  the  MBone  VCR  record  button. 

The  MBone  VCR  waits  for  the  first  packets  of  data  to  arrive  via  the  multicast 
address/port  and  begins  recording.  In  a  separate  UNIX  shell  listing,  the  files  in  the  target 
directory  using  the  UNIX  command  Is -la  shows  the  set  of  files  that  is  created  and 
shows  that  the  file  size  as  data  is  being  collected  in  those  files.  This  process  is  followed 
for  all  three  of  the  recording  experiments  with  much  the  same  result.  The  origin  of  the 
data  did  not  affect  the  VCR  in  any  adverse  way.  In  all  cases  the  same  set  of  fiOies  is  created 
and  the  files  increased  in  size  as  the  recording  time  increased.  For  all  experiments  we  used 
default  bandwidth  settings  for  vat  PCM  audio  (64  Kbps)  and  vie  H.261  video  (128  Kbps). 

The  file  sizes  differ  slightly  with  the  different  transmission  origins  but  that  can  be 
attributed  to  the  packet  loss  increases  as  the  distance  between  transmitting  workstation 
and  receiving  workstation  increases.  File  sizes  are  noticeably  smaller  when  the  receiving 
network  has  a  heavy  load.  This  can  also  be  attributed  to  the  quality  of  signal  received  by 
the  recording  workstation.  On  average,  the  total  amount  of  data  collected  in  the  five  files 
for  each  session  is  approximately  1.3  MB  per  minute  (just  under  the  capacity  of  a  3.5" 
floppy  diskette)  or  6.5  MB  per  five  minute  period.  Of  interest  is  the  fact  that  this  rate 
corresponds  to  approximately  78  MB/hour,  comfortably  less  than  the  90  MB/hour  storage 
rate  predicted  in  Figure  5.2. 

D.  PLAYING  A  RECORDED  SESSION 

The  next  step  in  evaluating  the  MBone  VCR  is  to  play  the  recorded  sessions. 
Playing  and  watching  the  recorded  sessions  is  accomplished  in  one  of  three  ways.  The 
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first  is  to  create  a  new  MBone  session  with  sd  or  scb".  Then  copy  the  advertised  multicast 
addresses  and  port  numbers  and  edit  the  recorded  session’s  media  to  match  the  new 
session  (MBone  VCR  provides  an  easy  way  to  accomplish  this).  Pressing  the  play  button 
on  the  GUI  then  plays  the  session.  This  test  was  performed  on  all  of  the  recordings 
mentioned  in  Section  1  above. 

Feedback  from  individuals  across  the  country  who  watched  a  global  rebroadcast  of 
a  session  reported  that  the  video  was  clear  but  the  audio  was  not  present  in  the 
transmission.  Remote  participants  watched  the  session  by  launching  vie  and  vat  from  sdr. 
When  launched  in  this  manner,  vat  is  started  with  the  -r  synchronization  switch.  The 
author  experienced  the  same  symptoms  on  the  local  network  and  on  the  same  workstation 
that  was  playing  the  session,  but  fixed  the  lack  of  audio  by  launching  vat  fi-om  the  UNIX 
command  line  without  the  -r  switch.  A  command  similar  to  the  following  was  used: 

vat  -f  pem  -t  127  -I  1  -C  "Test  Session"  224.2.230.15/65042 
Without  the  -r,  the  audio  portion  of  the  session  was  heard  clearly.  This  VCR  bug  has 
been  reported  and  is  expected  to  be  fixed  in  the  near  future.  No  feedback  was  received 
from  anyone  outside  of  the  local  network  once  the  audio  problem  was  fixed  locally. 

Further  tests  showed  that  this  lengthy  command  line  entry  was  not  needed.  Simply 
specifying  the  tool  and  the  address/port  numbers  will  allow  the  user  to  receive  the  signal. 
The  actual  command  line  entry  needed  is  as  follows: 

vat  224.2.230.15/65042 

The  second  technique  of  playing  a  recorded  session  is  to  create  a  new  MBone 
session  by  manually  setting  the  multicast  addresses  and  port  numbers  to  match  those  that 
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were  used  by  the  original  transmission  at  the  time  of  recording.  Watching  each  of  the 
three  rebroadcasts  using  sdr  to  launch  vie  and  vat  provides  the  same  results  as  above.  As 
long  as  vat  is  launched  from  the  command  line  without  the  -r  synchronization  switch,  the 
audio  is  heard.  Properly  using  the  -r  does  not  allow  vat  to  receive  the  data  being 
transmitted  by  the  MBone  VCR  if  the  -r  was  not  used  to  transmit  the  original  signal.  If 
the  -r  is  used  when  transmitting  the  original  recorded  session,  the  audio  will  be  heard  with 
or  without  using  the  -r  when  receiving  the  signal  transmitted  by  the  MBone  VCR.  This 
confusing  state  of  affairs  will  be  much  simpler  when  the  bug  is  corrected. 

The  third  technique  of  playing  the  recorded  sessions  is  to  simply  load  a  session  and 
click  on  the  play  button  without  creating  a  new  session  in  sdr.  The  drawback  here  is  that 
no  advertisement  of  the  playing  session  is  sent  out  to  the  local  or  global  MBone. 

However,  if  the  session  is  launched  locally  or  from  a  web  page,  the  exact  command  line 
entries  needed  to  watch  the  session  with  vie  and  vat  are  given  before  play  begins.  No 
global  unadvertised  multicasts  have  been  originated  using  this  method,  in  deference  to 
MBone  usage  conventions  (Macedonia,  Brutzman,  1994).  Locally  the  session  can  be 
watched  as  clearly  as  the  original  multicast.  This  third  approach  is  not  recommended  for 
normal  us  and  is  only  documented  here  for  completeness. 

E.  RECORDING  A  COMPLETE  LECTURE 

The  tests  up  to  this  point  had  shown  that  the  MBone  VCR  can  be  used  for  short 
periods  vwthout  failing.  The  next  step  was  to  record  an  entire  lecture  or  conference  to 
examine  the  performance  for  an  extended  period  of  time  (1-2  hours).  The  session  that 
was  chosen  was  the  video  tape  of  the  August  1996  SIGGRAPH  Virtual  Reality  Modeling 
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Language  (VRML)  Special  Interest  Group  (SIG).  The  video  tape  was  multicast  from  one 
workstation  using  vat  and  vie  and  recorded  on  another  using  the  MBone  VCR.  Again  the 
default  bandwidth  for  audio  and  video  were  used  and  the  file  sizes  increased  as  the 
recording  time  increased.  The  tape  was  slightly  longer  than  two  hours  and  the  five  files 
created  by  the  MBone  VCR  totaled  slightly  less  than  156  MB,  approximately  75  MB  per 
hour  of  recording.  This  number  is  of  interest  since  it  shows  that  and  entire  lecture  series 
(30+  lectures)  might  fit  into  less  than  2  GB  of  storage  space. 

F.  WEB  PAGE/CGI  SCRIPT  LAUNCH 

After  testing  the  MBone  VCR,  the  next  step  was  to  test  the  combo-form 
and  perl  scripts  that  let  a  user  select  an  MBone  session  from  the  recordings  and 
automatically  start  the  playback  of  the  selected  session  through  the  use  of  a  macro 
command  file  generated  by  the  perl  script.  The  perl  scripts  and  the  HTML  that  generates 
the  combo-form  can  be  found  in  Appendix  B.  The  use  of  the  macro  command  file  is 
explained  in  detail  in  Appendix  C.  The  URL  for  the  Web  page  is 
http:/Avww.stl.nps.navy.mil/~iirg/metidify/player Jrames.html 

The  Web  page  interface  was  tested  by  selecting  a  session  from  the  drop-down 
menu,  selecting  a  media,  giving  a  playback  start  time,  and  giving  a  session  ttl.  The  submit 
button  was  then  clicked  and  the  results  page  correctly  showed  the  information  that  had 
been  entered  into  the  form.  The  macro  command  file  was  opened  in  a  text  editor  to  see  if 
the  proper  commands  had  been  entered  into  it.  All  of  the  appropriate  commands  to  launch 
the  MBone  VCR  had  been  correctly  written  to  the  file. 
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Next  the  submit  button  generated  by  the  first  script  and  the  command  file  itself 
were  tested.  The  Web  page  returned  and  error  indicating  that  the  script  was 
malfunctioning.  The  syntax  of  the  script  was  checked  and  returned  no  errors.  The  script 
was  then  run  fi'om  the  UNIX  command  line.  Doing  this  showed  that  the  -c  option  in  the 
MBone  VCR  (which  allows  the  application  to  be  started  from  the  command  line  using  a 
macro  command  file)  was  not  functioning  properly.  The  MBone  VCR  was  started  but  the 
macro  command  file  was  not  read.  However,  using  the  “macro”  menu  option  in  the 
MBone  VCR  interface  to  test  the  command  file  showed  that  it  did  successfully  load  and 
play  the  proper  recorded  session.  Once  the  -c  option  in  the  MBone  VCR  is  functional,  the 
automatic  playback  system  is  also  expected  to  function.  This  software  bug  has  also  been 
reported. 

G.  FTP  RETRIEVAL 

The  final  step  in  the  testing  process  was  to  exercise  the  ftp  retrieval  method  in 
order  to  ensure  the  data  in  the  .tar.gz  file  was  not  corrupted  in  the  tar/compress 
uncompress/untar  process.  The  file  was  first  transferred  from  the  DMF  to  the  local 
network.  Next  the  commands  listed  in  Figure  5.4  were  used  to  uncompress  and  untar  the 
files.  The  session  was  then  loaded  into  the  MBone  VCR  and  played  over  the  local 
network.  The  session  was  watched  on  the  workstation  that  was  running  MBone  VCR  and 
another  workstation  on  the  same  network.  Both  receiving  workstations  used  vat  and  vie 
launched  from  the  command  line.  The  session  was  viewed  as  clearly  as  before  it  was 
archived  on  the  DMF.  The  DMF  archive  location  is  on  s  ir  ius .  cc .  nps .  navy . mi  1 
in  directory  /h/dl/iirg. 


47 


H.  EVALUATION  OF  RESULTS 


All  of  the  MBone  sessions  were  recorded  in  three  different  ways  and  the  three 
methods  of  playback  were  attempted  on  each  of  the  three  recorded  sessions.  The  testing 
was  performed  using  the  VCR’s  GUI  and  a  combination  of  5ci^-launched  and  command- 
line-launched  MBone  tools. 

In  all  experimental  cases  the  default  transmission  rates  on  the  audio  and  video 
provided  a  clear  reproduction  of  the  original  audio/video  session.  Using  the  default  video 
quality  level  of  10  during  recording  seemed  to  strike  the  best  balance  between  quality  of 
picture  and  movement  during  playback.  Participants  were  able  to  read  any  slides  that  the 
instructor  or  lecturer  used  and  the  frame  rate  was  sufficient  for  meaningful  expression  of 
gestures.  Facial  expressions  can  sometimes  be  discerned  usefully  at  this  frame  rate.  No 
experiments  were  conducted  using  the  MBone  whiteboard  (wb)  tool  to  transmit  slides 
since  the  MBone  VCR  does  not  yet  support  wb. 

The  results  of  the  audio/video  testing  are  satisfactory  and  demonstrate  successful 
recording  and  playback.  These  various  combinations  of  tests  successfully  demonstrated  all 
of  the  software  test  goals  listed  in  Figure  6. 1 . 

1.  SUMMARY 

This  chapter  provides  the  results  of  experimental  testing  performed  using  the 
MBone  VCR.  Each  experiment  is  discussed  as  it  relates  to  the  six  goals  outlined  in  the 
overview  of  the  experimental  process.  The  chapter  then  explains  the  results  attained  when 
an  entire  conference  was  recorded  and  the  two  retrieval  methods  were  tested.  The 
chapter  ends  with  an  evaluation  of  the  experimental  results. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  RESEARCH  CONCLUSIONS 

The  MBone  VCR  has  been  successfully  implemented  on  a  local  basis  around  the 
NPS  campus.  Limited  success  was  achieved  on  a  larger  scale,  however  the  level  of 
success  cannot  be  measured  due  to  the  minimal  feedback  from  remote  sites.  It  is  easy  to 
see  that  the  MBone  VCR  can  help  enhance  the  capabilities  of  the  world-wide  multimedia 
teleconference  and  distance  education  already  taking  place  on  the  Multicast  Backbone 
(Holfelder,  1995).  Further  testing  and  development  is  needed  to  better  quantify  these 
conclusions. 

The  video  quality  of  the  recordings  is  not  yet  clear  enough  for  feature  films,  but 
sacrificing  a  small  amoimt  of  quality  provides  for  manageable  file  sizes.  This  is  extremely 
important  when  looking  at  the  distance  learning  concept  from  an  economic  standpoint.  At 
this  point  in  the  use  of  the  MBone  VCR,  the  quality  of  the  recording  is  only  as  good  as  the 
original  MBone  broadcast.  As  the  MBone  tools  continue  to  improve  so  will  the  quality  of 
the  recorded  sessions.  As  a  result  of  this  research,  the  realm  of  distance  education  is  one 
step  closer  to  being  truly  independent  of  time  and  geographic  location. 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

The  technical  aspects  of  research  such  as  this  are  only  part  of  the  story  when  the 
overall  results  can  affect  people’s  lives.  Once  the  technology  has  been  proven  to  work, 
the  next  step  is  to  look  at  how  it  can  be  integrated  into  daily  life.  The  whole  purpose  of 
the  concept  of  distance  education  is  to  help  people  learn.  Therefore,  research  on  the 
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human  aspect  of  distance  education  needs  to  include  a  look  at  how  the  content  of  a  class 
or  conference  is  best  tailored  for  effective  distance  delivery.  Correcting  the  few  remaining 
bugs  in  the  technical  results  of  this  thesis  will  enable  such  research. 

While  the  tests  on  the  MBone  VCR  were  successful,  there  are  several  areas  that 
could  be  improved  in  future  versions  of  the  application.  Since  the  MBone  tools  are 
already  available  for  most  PC  platforms,  the  next  logical  step  for  the  VCR  would  be  to 
port  the  program  to  PC  operating  systems.  This  would  allow  even  the  smallest  networks 
that  may  have  high-speed  internal  connections  to  download  the  recorded  sessions  and  play 
them  locally  (assuming  their  outside  network  connections  do  not  support  higher  speeds). 
This  can  also  open  the  possibility  of  putting  the  recorded  sessions  on  CD-ROM  and 
allowing  individuals  who  may  have  no  network  connection  at  all  to  watch  the  sessions  on 
their  own  home  systems.  The  numbers  of  people  able  to  participate  in  distance  education 
programs  then  begins  to  grow  exponentially. 

Another  needed  improvement  to  the  MBone  VCR  is  compatibility  with  the 
redundant  audio  encodings  used  in  rat.  The  use  of  FEC  provides  notable  performance 
enhancement  during  periods  of  poor  network  performance  without  increasing  the  required 
bandwidth.  We  recommend  that  video  archives  be  recorded  using  redundancy. 

Several  improvements  can  also  be  made  to  the  MBone-on-Demand  system  at  NPS. 
Currently  the  system  has  no  way  of  restricting  the  number  of  sessions  playing  at  one  time. 
One  piece  of  fixture  work  might  be  to  complete  a  lockfile  system  limiting  the  number  of 
global  multicast  sessions  so  the  system  does  not  overrun  the  whole  MBone.  The 
Hamming  lecture  series  that  was  multicast  for  an  entire  quarter  is  ready  to  be  digitally 
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stored  osing  the  redundant  encoding  in  rat  (when  it  is  made  compatible  with  MBone 
VCR)  and  vie.  Other  additions  to  the  system,  such  as  getting  permanently  assigned 
multicast  addresses  and  port  numbers  for  a  global  MBone  VCR  channel  will  continue  to 
make  it  easier  to  use  and  more  readily  accessible. 

As  with  any  new  software  tool,  more  testing  is  needed.  Playing  and  recording 
remotely  across  different  networks  and  different  platforms  has  only  begun.  Now  that  the 
VCR  tool  is  here  and  useable,  it  can  only  get  better  and  become  more  beneficial. 
Important  additional  work  includes  automatic  local  launch  of  appropriate  MBone  tools, 
perhaps  using  Java  applets. 

Finally^  as  Seen  in  “The  Digital  Library  Phenomenon;  Opportunities  and 
Implications  for  the  Naval  Service,”  the  Naval  service  can  benefit  tremendously  from 
meeting  non-tactical,  day-to-day  information  needs  (Norris,  West,  1996).  The  digital 
library  is  a  concept  that  is  catching  on  quickly  throughout  today’s  educational 
infrastructure.  As  that  concept  grows  into  actual  systems,  one  goal  for  the  educators 
involved  can  be  to  incorporate  distance  educational  systems  like  the  MBone-on-Demand 
system  discussed  in  this  thesis  into  the  overall  infrastructure.  We  look  forward  to  the  day 
when  the  use  of  tools  such  as  the  MBone  VCR  is  widespread  and  easy. 
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APPENDIX  A:  GLOSSARY 


ACM  -  Association  for  Computing  Machinery:  A  large  and  long-standing  professional 
organization  dedicated  to  most  of  the  important  issues  related  to  computers. 

Anonymous  ftp:  A  log-on  convention  used  by  Internet  that  lets  a  user  retrieve  files  from 
a  file  transfer  protocol  (ftp)  server,  even  though  the  user  may  not  have  an  account  on  that 
server. 

ANSI  -  American  National  Standards  Institute:  The  primary  standards  organization  in 
theU.S. 

ATM  -  Asynchronous  Transfer  Mode:  International  standard  for  cell  relay  in  which 
multiple  service  types  (such  as  voice,  video,  or  data)  are  conveyed  in  fixed-length 
(53-byte)  cells.  Fixed-length  cells  allow  cell  switching  to  occur  in  hardware,  thereby 
reducing  transit  delays.  ATM  is  designed  to  take  advantage  of  high-speed  transmission 
media  such  as  fiber  optic  cable. 

Compression:  The  art/science  of  reducing  the  number  of  bits  required  to  store  and/or 
transmit  digital  media.  Predominant  schemes  include  MPEG  1,  MPEG  2,  motion  JPEG. 
MPEG  performs  intra-frame  compression  as  well  as  inter-frame  (or  differences  from 
frame-to-frame)  compression.  JPEG,  which  is  predominantly  a  still-image  compression 
scheme,  performs  only  intra-frame  compression. 

Digitization:  The  art/science  of  converting  analog  video,  images,  or  audio  into  digital 
format  (i.e..  Is  and  Os) 

Hypertext  Markup  Language  -  HTML:  The  source  language  for  making  World  Wide 
Web  2D  hypermedia  pages.  HTML  not  only  formats  a  Web  page,  but  also  provides  for 
links  to  other  Web  pages  or  documents. 

Hypertext  Transfer  Protocol  -  HTTP:  The  Internet  protocol  that  enables  the  World 
Wide  Web.  This  is  the  protocol  designed  for  serving  HTML  documents.  It  is  a 
client/server-based  protocol. 

IEEE  -  Institute  of  Electrical  and  Electronics  Engineers:  Professional  organization 
whose  activities  include  the  development  of  communications  and  network  standards.  IEEE 
LAN  standards  are  the  predominant  LAN  standards  today. 

IETF  -  Internet  Engineering  Task  Force:  Task  force  consisting  of  over  80  working 
groups  responsible  for  developing  Internet  standards. 
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Internet:  Term  used  to  refer  to  the  largest  global  internetwork,  connecting  tens  of 
thousands  of  networks  worldwide  and  having  a  "culture"  that  focuses  on  research  and 
standardization  based  on  real-life  use.  Many  leading-edge  network  technologies  come 
from  the  Internet  community.  The  Internet  evolved  in  part  from  ARPANET.  At  one  time, 
called  the  DARPA  Internet.  Not  to  be  confused  with  the  generic  term  internet. 

internet:  Short  for  internetwork.  While  an  internet  is  a  network  that  uses  the  same 
technology  (such  as  TCP/IP),  the  term  "internet"  is  usually  used  to  refer  to  a  collection  of 
such  networks  interconnected  with  routers.  Not  to  be  confused  with  the  global  Internet. 

IP  -  Internet  Protocol:  Network  layer  protocol  in  the  TCP/IP  stack  offering  a 
connectionless-routed  internetwork  service.  IP  provides  features  for  addressing, 
type-of-service  specification,  fragmentation  and  reassembly,  and  security. 

IP  address:  32-bit  address  IPv4  (or  128-bit  address  in  IPV6)  assigned  to  hosts  using 
TCP/IP.  An  IPv4  address  belongs  to  one  of  five  classes  (A,  B,  C,  D,  or  E)  and  is  written 
as  4  octets  separated  with  periods  (dotted  decimal  format).  Each  address  consists  of  a 
network  number,  an  optional  subnetwork  number,  and  a  host  number.  The  network  and 
subnetwork  numbers  together  are  used  for  routing,  while  the  host  number  is  used  to 
address  an  individual  host  within  the  network  or  subnetwork.  A  subnet  mask  is  used  to 
extract  network  and  subnetwork  information  from  the  IP  address.  Also  called  an  Internet 
address  or  host  address. 

IP  multicast:  Routing  technique  that  allows  IP  traffic  to  be  propagated  from  one  source 
to  many  destinations  or  from  many  sources  to  many  destinations.  Rather  than  sending 
duplicate  packets  to  each  destination,  each  packet  is  sent  to  a  multicast  group  identified  by 
a  single  IP  destination  group  address.  Packet  replication  occurs  at  routers  in  a  classical 
router-based  network.  Multicast  traffic  uses  class  D  IP  addresses. 

LAN  -  Local-Area  Network:  High-speed,  low-error  data  network  covering  a  relatively 
small  geographic  area  (up  to  a  few  thousand  meters).  LANs  connect  workstations, 
peripherals,  terminals,  and  other  devices  in  a  single  building  or  other  geographically 
limited  area.  LAN  standards  specify  cabling  and  signaling  at  the  physical  and  data  link 
layers  of  the  OSI  model.  Ethernet,  FDDI,  and  Token  Ring  are  widely  used  LAN 
technologies. 

MPEG  1  -  Motion  Picture  Experts  Group:  Compressed  digital  video/audio  stream. 
MPEG  1  is  1/4  broadcast  quality  which  translates  to  352x240  pixels.  Typically 
compressed  at  1.5  Mbps.  Pronounced  "m-peg". 

MPEG  2  -  Motion  Picture  Experts  Group:  Compressed  digital  video/audio  stream. 
MPEG  2  is  broadcast  quality  and  translates  to  704x480  pixels  at  30  frames  per  (fps) 


54 


second  in  North  America  and  704x576  fps  at  25  fps  in  Europe.  Currently  a  draft  standard. 
Typically  compressed  at  higher  than  5  Mbps  and  meant  for  higher  quality/broadcast  uses. 

Multicast  Backbone  (MBone):  A  virtual  network  that  provides  many-to-many  global 
network  delivery  services  for  applications  such  as  videoconferencing  and  audio  where 
several  hosts  need  to  communicate  simultaneously.  Provides  multicast  connectivity 
between  LANs  across  the  Internet. 

Multicasting:  The  ability  of  an  application  to  send  a  single  message  to  the  network  and 
have  it  delivered  to  multiple  recipients  at  possibly  different  locations. 

PCM  -  Pulse-Code  Modulatiou:  Transmission  of  analog  information  in  digital  form 
through  sampling  and  encoding  the  samples  with  a  fixed  number  of  bits.  Refers  to  a 
commonly  used  audio  encoding  algorithm. 

RFC  -  Request  For  Comments:  Document  series  used  as  the  primary  means  for 
communicating  information  about  the  Internet.  Most  RFCs  document  protocol 
specifications  (e.g.  telnet  and  ftp).  A  complete  index  of  RFCs  is  available  at 
http://dis.  intemic.  net/rfc/ 

Rlogin  -  remote  login:  Terminal  emulation  program  (similar  to  telnet)  offered  in  most 
UNIX  implementations.  Passwords  are  not  encrypted  during  transmission. 

TCP  -  Transmission  Control  Protocol:  Connection-oriented  transport  layer  protocol 
that  provides  reliable  full-duplex  data  transmission.  TCP  is  part  of  the  TCP/IP  protocol 
suite  at  the  same  level  as  best-effort  UDP. 

TCP/IP  -  Transmission  Control  Protocol/Intemet  Protocol:  Common  name  for  the 
suite  of  protocols  developed  by  the  U.S.  DoD  in  the  1970s  to  support  the  construction  of 
world-wide  internetworks.  Common  protocol  suite  used  throughout  the  Internet. 

telnet:  Standard  terminal  emulation  protocol  in  the  TCP/IP  protocol  stack,  telnet  is  used 
for  remote  terminal  connection,  enabling  users  to  log  in  to  remote  systems  and  use 
resources  as  if  they  were  connected  to  a  local  system.  Passwords  are  not  encrypted  during 
transmission. 

Time  to  Live  (ttl):  A  counter  used  to  limit  multicast  packet  lifetimes.  A  threshold  that  a 
multicast  datagram  needs  to  be  forwarded  onto  a  given  tunnel. 

Unicasting:  One  host  exchanging  packets  with  another  single  specific  host. 

URL  -  Uniform  Resource  Locator:  Standardized  addressing  scheme  for  identifying 
hypertext  documents  and  other  services  using  a  Web  browser. 
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Video  Teleconferencing  (VTC):  A  two-way  electronic  form  of  communication  that 
permits  two  or  more  people  in  different  locations  to  engage  in  face-to-face  audio  and 
visual  communication.  Meetings,  seminars,  and  conferences  can  be  conducted  as  if  all 
participants  are  in  the  same  room. 

Video  Teletraining:  The  use  of  point-to-point  or  multi-point  teleconferencing  to  provide 
interactive  remote  site  training. 

WAN  -  Wide-Area  Network:  Data  communications  network  that  serves  users  across  a 
broad  geographic  area,  often  uses  transmission  services  provided  by  common  carriers. 

WWW  (Web)  -  World  Wide  Web:  Large  network  of  Internet  servers  providing 
hypertext  and  other  services  to  terminals  running  client  applications  such  as  a  Web 
browser.  More  generally,  all  information  resources  available  via  the  Internet. 

Web  browser:  Hypertext  client  application  (such  as  Mosaic  or  Netscape)  used  to  access 
hypertext  documents  and  other  services  located  on  innumerable  remote  servers  throughout 
the  Web  and  the  Internet.  Text-based,  graphical  user  interface  (GUI)  and  3D  graphics 
browsers  using  the  Virtual  Reality  Modeling  Language  (VRML)  are  also  available. 
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APPENDIX  B:  HTML  FOR  MBONE  PLAYER  PAGE  AND 
CGI/PERL  SESSION  RETRIEVAL  SCRIPTS 


HTML  for  the  MBone  Player  Page 

This  section  is  the  listing  of  the  HTML  that  produces  the  combo-form.  This 
HTML  provides  the  user  interface  on  the  NFS  MBone  player  page.  The  URL  of  the  Web 
page  is  http://www.stl.nps.ncivy.mil/~iirg/tiddy/player  Jrames.html 


<html> 

<head> 

<title>  NPS  MBone  Player  Page</title> 

</head> 

<h2  align=center>NPS  <i>MBone  </i>Playback</h2> 

<center><p> 

<form  method=post  action=”cgi-bin/vcr_input .cgi” 
target=”results_window”> 

<table  border=10  cellspacing=0  cellpadding=5> 

<caption  align=top></caption> 

<tr> 

<th  align=center><font  size  =  4>User  Inf ormation</ font  size  =  4></th> 
</tr> 


<tr> 


<td  align=center> 

<br><input  type=text  naine=name 
</td> 

</tr> 


size=12  value="UserName?”></p></center> 


<tr> 

<th  align=center><font  size  =  5>Select  a  Session</font  size  =  5</th> 
</tr> 


<tr> 

<td> 

Hainraing 

<select 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 

<option 


Lectures 


name=session  align=right> 
value-" 1”  selected>  1—  DD/MM/YY 


value="2"> 
value-" 3"> 
value-" 4 "> 
value-"5"> 
value="6"> 
value-" 7 "> 
value-" 8 "> 
value-" 9 "> 
value="10"> 
value-" 11 "> 
value-" 12 "> 
value="13"> 
value-" 14 "> 


2 —  DD/Jm/YY 

3—  DD/MM/YY 

4 —  DD/MM/YY 

5—  DD/MM/YY 

6 —  DD/MM/YY 
7“—  DD/MM/YY 

8 —  DD/MM/YY 

9 —  DD/MM/YY 

10 —  DD/MM/YY 

11 —  DD/MM/YY 

12 —  DD/MM/YY 

13 —  DD/MM/YY 

14 —  DD/MM/YY 
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<option  value="15"> 
<option  value="16"> 
<option  value="17"> 
<option  value="18"> 
<option  value="19"> 
<option  value="20"> 
<option  value="21"> 
<option  value="22"> 
<option  value="23"> 
<option  value="24"> 
<option  value=”25"> 
<option  value="26"> 
<option  value="27"> 
<option  value="28"> 
<option  value="29"> 
<option  value="30"> 
<option  value="31"> 
</select> 

</td> 

</tr> 


15 —  DD/MM/YY 

16 —  DD/MM/YY 

17 —  DD/MM/YY 

18 —  DD/MM/YY 

19—  DD/MM/YY 

20 —  DD/MM/YY 

21 —  DD/MM/YY 

22 —  DD/MM/YY 

23 —  DD/MM/YY 

24 —  DD/MM/YY 

25 —  DD/MM/YY 

26 —  DD/MM/YY 

27 —  DD/MM/YY 

28 —  DD/MM/YY 

29 —  DD/MM/YY 

30 —  DD/MM/YY 
SIGGRAPH  VRML  SIG 


<tr> 

<td> 

<center>Media  Type&#160  &#160 
<select  name=media> 

<option  selected  value="audio_and_video">Audio  and  Video 
<option  value="audio">Audio  Only 
<option  value="video">Video  Only 
</select></center> 

</td> 

</tr> 

<tr> 

<th  align=center><input  type="submit"  value="Submit  Playback 
Information">  </th> 

<tr> 

<th  align=center><input  type="reset"  value=''Reset  Defaults"></th> 

<tr> 

<th>&#160</th> 

</tr> 

<tr> 

<th  align=center><font  size  =  5>  Advanced  Options</f ont  size  =  5></th> 
</tr> 

<tr> 

<td  align=center> 

<align=left><p>Playback  Start  time  (PDT) 

<input  type=text  name=start_time  size=17  value="HH:MM: SS  MM/DD/YY"><br> 
If  you  need  help,  here's  a 

<a  href="http: / /poisson . ecse . rpi . edu/ cgi-bin/tzconvert" 
target="_top"> 

timezone  converter</a> . 

</td> 

</tr> 

<tr> 
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<td  align=right> 

<center><p>Multicast  time-to-live  (ttl)  scope 
<br><select  name=ttl  align=right> 

<option  value=”l”>l:  local-area  network  (LAN) 

<option  value="15”  selected>15:  NPS 

campus  <option  value="32">31 :  Monterey  Bay  (approx.) 

<option  value="128”>127 :World-wide  MBone 
<option  value=”171">171 :  Global  audio  MBone 
</select> 

</td> 

</tr> 

<tr><td><center> 

You  can  also  download  the  entire  series  as  .tar  files  by  going  to  the 
Lecture  Series 

<a  href  ="http :  //www.  stl .  nps . navy , mil/'-iirg/tiddy/hamming^archive/ " 
target^” result s_window" > 

FTP  Archive</a>.</center> 

</tr> 


</table> 

</fonn></center> 

<P> 

<P> 

<hr> 

Last  update:  12  September  1996 
</body> 

</html> 
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VCR  Input  Script 


# ! /usr/local/bin/perl 

# 

#vcr_input 

# 

#  This  script  takes  input  from  a  combination  form 

#  echos  that  information  on  a  second  Web  page  and 

#  writes  the  information  to  a  macro  command 

#  file  that  will  be  used  by  the  VCR  to  play  the 

#  chosen  MBone  session. 

# 

#  Michael  Tiddy  <metiddy@nps .navy .mil> 

#  17  Sept.  1996 

#  http : / /WWW . s tl . nps . navy , mil /-iirg/ tiddy/ vcr_input . cgi 

# 

#  References: 

# 

#  Herrmann,  Eric,  Teach  Yourself  CGI  Programming  with 

#  Perl  in  a  Week,  first  Edition,  Sams.net  Publishing,  1996. 

# 

#  Tiddy,  Michael  E.,  Internetworking:  Economical  Storage 

#  and  retrieval  of  Digital  Audio  and  Video  for  Distance 

#  Learning,  Master's  Thesis,  Naval  Postgraduate 

#  School,  Monterey,  California,  September  1996. 

# 

#  Wall,  Larry,  and  Schwartz,  Randal  L. , 

#  Programming  Perl,  O'Reilly  &  Associates,  Inc.,  1991. 

# 

# 

# 

# 

push (@INC,  "/cgi -bin”) ; 
require ( "cgi-lib. pi") ; 

require ("ctime.pl") ; 

&ReadParse (*input) ; 

#Get  the  User__name 
$user_name  =  $input { *name * } ; 

$mydate  =  'date'; 

if  ($input{ *start_time* }  eq  "HH:MM:SS  MM/DD/YY")  { 

$start  =  "$mydate"; 

} 

else  { 

$start  =  $input { * start_time * } ; 

} 


#Detennine  the  lecture  chosen 

if  ($input{ *  session* }  eq  "1")  { 

$session_name  =  "Hamming  1_MM/YY"; 

} 
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elsif  ($input{ *  session’ }  eq  "2”)  { 

$session_name  =  "Hainining2_MM/Yy"; 

} 

elsif  ($input{ ’session’ }  eq  ”3")  { 

$session__name  =  ”Hamming3_MM/yy”; 

) 

elsif  ($input{ ’session’ }  eq  ”4”)  { 
$session_name  =  ’’Hainming4__MM/yy’’ ; 

} 

elsif  ($input{ ’ session’ }  eq  "5")  { 

$session_naiae  =  "Hainining5_MM/yy”; 

} 

elsif  ($input{ ’ session* }  eq  ”6”)  { 

$session_name  =  ”Hamniing6_MM/yy" ; 

} 

elsif  ($input{ ’ session’ }  eq  "7")  { 

$session__name  =  ”Hainining7_MM/yy"; 

} 

elsif  ($input{ ’ session’ }  eq  ”8”)  { 
$session_naine  =  ”Hainming8_MM/yy"; 

} 

elsif  ($input{ ’ session’ }  eq  "9”)  { 

$session_name  =  ”Hairiraing9__MM/yy'’; 

} 

elsif  ($input{ ’session’ }  eq  "10")  { 

$session_name  =  ”HaiimiinglO_MM/yy’*; 

} 

elsif  ($input{ ’ session’ }  eq  "11")  { 

$session_name  =  "Haminingll_MM/yy"; 

} 

elsif  ($input{ ’ session’ }  eq  "12")  { 

$session_naine  =  "Haminingl2_MM/yy"; 

} 

elsif  ($input{ ’session’ }  eq  "13")  { 

$session___name  =  "Haininingl3___MM/yy"; 

) 

elsif  {$input{ ’ session  * }  eq  "14")  { 

$session_name  =  "Hamming  14__MM/yy”; 

} 

elsif  ($input{ *  session’ }  eq  "15")  { 

$session_name  =  "Hammingl5_MM/yy 

} 

elsif  ($input{ ’ session  * }  eq  "16")  { 

$session_name  =  "Hammingl6_MM/yy"; 

} 

elsif  ($input{ *  session  * }  eq  "17")  { 

$session_name  =  "Haminingl7_MM/yy"; 

} 

elsif  ($input{ ’session* }  eq  "18")  { 

$session_name  =  "Hainiriingl8_MM/yy”; 

} 

elsif  ($input{ *  session’ }  eq  "19")  { 

$session__name  =  "Hammingl9_MM/yy"; 

} 

elsif  ($input {* session ’ }  eq  "20")  { 

$session_name  =  "Harnrning20_MM/yy"; 

} 

elsif  ($input{ ’ session’ )  eq  "21")  { 
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$session_name  =  "Hamining21_MM/yY"; 

} 

elsif  ($input{ 'session' }  eq  ”22")  { 
$session_name  =  "Hainming22_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "23")  { 
$session_naine  =  "Hainming23_MM/YY"; 

} 

elsif  ($input{ ' session' }  eq  "24")  { 
$session_naine  =  "Hainming24_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "25")  { 
$session_name  =  "Hainitiing25_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "26")  { 
$session_nanie  =  "Hainming26_MM/YY"; 

} 

elsif  ($input{ ' session' }  eq  "27")  { 
$session_name  =  "Hamming27_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "28")  { 
$session_name  =  "Hainming28_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "29")  { 
$session_name  =  "Hamiaing29_MM/YY"; 

} 

elsif  ($input{ ' session' }  eq  "30")  { 

$session_name  =  "Haitiming30_MM/YY"; 

} 

elsif  ($input{ 'session' }  eq  "31")  { 

$session_naine  =  "SIGGRAPH_VRML_SIG"; 

} 


#get  requested  ttl  from  combo-form  user  input 
$session_ttl  =  $input{ 'ttl' } ; 

#get  requested  media  types 
$media_type  =  $input{ 'media' } ; 
if  ($ input { 'media' )  eq  "audio") 

{$tooll  =  "vat  224.2.222.204\/29366  \&" 
$tool2  =  "No  video  tool"; 

} 

elsif  ($ input { 'media ' }  eq  "video") 

{$tooll  =  "No  audio  tool"; 

$tool2  =  "vie  224.2. 170. 70\/65114  \&"; 

} 

elsif  ($ input { 'media' )  eq  "audio_and_video") 
{$tooll  =  "vat  224.2.222.204\/29366  \&" 
$tool2  =  "vie  224.2.170.70\/65114  \&"; 

} 


print  "Content-type:  text/html\n\n"; 
print "<html>\n"; 
print "<head>\n"; 

print"<title>  NPS  MBone  Player  Page</title>\n 

print"</head>\n'' ; 

print"<body>\n"; 
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print ”<h2  align=center>NPS  <i>MBone  </i>Playback</h2>\n"; 
print ”<center>\n”; 

print ”<table  border=5  cellspacing=0  cellpadding=5>\n** ; 

print ”<tr  align=center>\n"; 
print”<td>\n" ; 

print "<h2>Hello  $user_name . <br>\n” ; 
print "It  is  $mydate.<br>\n”; 

print "This  is  your  playback  information! </h2>\n"; 
print"</tr>\n"; 

print"<tr  align=left>\n”; 
print "<td>\n" ; 
print "<ul>\n”; 

print"<li>You  have  chosen  the  following 
session: <br>$session_name<br>\n"; 

print "<li>You  have  chosen  $media_type  as  your  media. <br>\n"; 
print "<li>Y our  start  time  is  $start  PDT.<br>\n”; 
print"<li>Your  ttl  is  $session_ttl<br>\n"; 
print ”</ul>\n"; 
print "</tr>\n" ; 

print "<tr  align=left>\n"; 
print "<td>\n”; 

print"You  need  to  use  the  following  commands  to  start  the  proper 
tool (s) :<br>\n"; 

print"<ul>\n"; 
print"<li>$tooll  <br>\n"; 
print"<li>$tool2  <br>\n"; 
print"</ul>\n"; 
print"</table>\n” ; 
print "</center>\n" ; 
print"<br>\n"; 

print "<center>\n" ; 

print"If  all  of  the  information  above  is  correct, <br>\n"; 
print "press  the  button  to  launch  the  playback. <br>\n"; 
print "<form  method=post  action=\"vcr_start.cgi\">\n"; 
print"<tr>\n"; 

if  ($input{ *start_time* }  eq  MM/DD/YY") { 

print "<th  align=center><input  type=\"submit\"  value=\ "Start 
Playing  Now\">\n"; 

} 

else  { 

print"<th  align=center><input  type=\ "submit \"  value=\ "Start 
Playing  at  $start\ ">\n"; 

} 

print "</th>\n"; 
print"</form>\n"; 
print"</center>\n" ; 
print "</body>\n"; 
print "</html>\n" ; 

#open  vcr  macro  file 

open  (CMD, ">/usr/local/videoData4/play. cmd")  ||  die  "can*t  open  $cmdfn: 
$!\n"; 
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#  start  playing  at  $start 

if  ($input{ *start_time* }  eq  "HH:MM:SS  MM/DD/YY") { 

print  CMD  **#play  starts  immediately,  $start\n"; 

} 

else  { 

print  CMD  "at  $start\n"; 

} 

#  load  session 

print  CMD  "load  /usr/local/videoData4/$session_name. vcr\n"; 
#start  playing 
print  CMD  "play\n”; 

#  play  for  2.0  hours 

print  CMD  "wait  02:00:00\n"; 

#  stop  playing 
print  CMD  **stop\n"; 

#  unload  $session_name 
print  CMD  ”unload\n"; 

#  quit  vcr 

print  CMD  **quit\n”; 

#close  macro  command  file 
close (CMD) ; 

exit; 
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VCR  Start  Script 


# ! /usr/local/bin/perl 

# 

#vcr_input 

# 

#  This  script  is  triggered  by  the  submit  button  created  by 

#  the  previous  script.  The  result  of  this  script  is  the 

#  playing  of  the  chosen  MBone  session. 

# 

# 

#  Michael  Tiddy  <metiddy@nps.navy.inil> 

# 

# 

#  17  Sept.  1996 

#  http :  /  /WWW.  stl .  nps .  navy  .mil/-'iirg/ tiddy/ vcr_input .  cgi 

# 

#  References: 

# 

#  Herrmann,  Eric,  Teach  Yourself  CGI  Programming  with 

#  Perl  in  a  Weekr  first  Edition,  Sams.net  Publishing,  1996. 

# 

#  Tiddy,  Michael  E.,  Internetworking:  Economical  Storage 

#  and  retrieval  of  Digital  Audio  and  Video  for  Distance 

#  Learning,  Master's  Thesis,  Naval  Postgraduate 

#  School,  Monterey,  California,  September  1996. 

# 

#  Wall,  Larry,  and  Schwartz,  Randal  L., 

#  Programming  Perlf  O'Reilly  &  Associates,  Inc.,  1991. 

# 

# 

# 

#  Make  cgi  interpreterstart  looking  for  libraries  and  functions 

#  your  own  directory 
push (@INC,  "/cgi-bin”) ; 

require ( "cgi-lib .pi” ) ; 

#set  the  path  to  the  VCR  executable  file 
$vcr  =  "/usr/local/bin/vcr”; 

#executes  the  VCR  command  with  the  -c  option  giving  the  path  name  to  the 
macro  # command  file 

exec  "$vcr  -c  /usr/local/videoData4/play. cmd 
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APPENDIX  C:  INSTRUCTIONS  FOR  BASIC  OPERATION  OF  THE 


MBONE  VCR 

This  user’s  guide  has  been  created  using  much  of  the  information  provided  by  the 
creator  of  the  MBone  VCR  in  the  postscript  file  that  accompanies  the  actual  program.  It 
is  designed  to  assist  anyone  that  desires  to  use  the  MBone  VCR  to  record  or  playback  a 
multicast  session.  There  are  no  instructions  here  for  connecting  to  the  MBone  or  using 
the  MBone  tools.  Information  on  either  of  those  topics  can  be  found  at  The  MBone 
Information  Web  available  at  http://www.best.com/~prince/techinfo/mbone.html 

OVERVIEW  OF  THE  MBONE  VCR 

A  session  recorded  by  VCR  can  consist  of  as  many  multicast  channels  as  a  user 
desires  to  record.  During  recording,  the  MBone  VCR  wdll  synchronize  these  time-critical 
data  streams  based  on  information  provided  by  protocols  such  as  RTPvl  or  RTPv2  (the 
Real  Time  Transport  Protocol).  The  MBone  VCR  does  not  need  to  know  which  particular 
application  originates  a  data  stream  or  what  the  exact  content  of  the  data  stream  is;  it 
suffices  that  the  data  stream  conforms  to  one  of  the  supported  protocols. 

To  play  back  a  recorded  session,  the  MBone  VCR  sends  the  data  out  to  the 
network,  recovering  the  original  timing  and  synchronization  of  all  the  media  streams 
included  in  this  session  and  using  the  same  network  protocols  used  by  the  applications 
from  which  the  data  was  recorded.  Therefore  users  run  these  application  in  order  to 
watch  and/or  listen  to  the  data  played  back  by  the  MBone  VCR. 
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The  main  MBone  VCR  window  tries  to  imitate  the  look  of  a  home  vcr.  The  left 


area  of  the  main  window  gives  some  status  information  about  the  loaded  session  whereas 
the  right  area  provides  a  session  clock  and  buttons  to  control  the  session. 

GETTING  THE  TOOLS 

The  free  MBone  tools  and  the  MBone  VCR  can  all  be  retrieved  using  ftp  from 
ftp: //ftp.  ucs.  ed  ac.  uk 

The  site  contains  a  description  as  well  as  an  index  to  the  source  and  binaries  for  all 
of  the  available  conferencing  tools  (Wood,  96).  Once  the  tools  have  been  transferred  the 
user  must  unzip  and  use  the  tar  -xvf  function  to  install  them  on  the  local  workstation  or 
network.  Each  tool  contains  a  README  file  help  with  any  further  installation 
requirements. 

To  use  the  MBone  VCR  you  will  also  need  TCL  version  7.5  and  TK  version  4.1 
installed  in  the  directory  tree  above  MBone  VCR.  If  the  user  does  not  have  root 
permission  and  cannot  fully  install  TCL/TK,  the  user  can  set  two  environment  variables  via 
the  command  line  or  in  .cshrc  with  entries  resembling  the  following; 
setenv  TCL_LIBRARY  ~/ [master  directory] 
setenv  TK_LIBRARY  ~ / [master  directory] 

The  current  versions  of  TCL  and  TK  can  be  found  at  ftp://ftp.smli.com/pub/tcl/ 
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USING  THE  MBONE  VCR 


MBoneVGRv1.3a01 


Session  Options  Speed  Record  Tools  Macro 


No  se5s'«in 


nnnnnn 

UUUU-IJIU 


mute'unmute' 


jtKseisansrifit.-.  jS3J'*>w<'«Kr«. 


ldxmode:gotd  start/end 


Idxniedla:* 


Toggle  indexcontrol  panel 


I  S^ods 


Total  time: 
0  ms 


Figure  C.  1 .  MBone  VCR  User  Interface 


shows  the  user  interface. 

The  following  sections  describe  the  basic  functions  available  to  the  users  of  the  MBone 


VCR. 
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OPEN  A  SESSION 


If  no  session  is  loaded,  "No  session"  is  displayed  in  the  status  area  of  the  VCR 
window  and  the  media  list  (below)  is  empty.  To  open  an  existing  session  one  can  either 
use  the  "Open  Session..."  entry  in  the  "Session"  menu  or  double  click  on  the  "No  Session" 
label.  Change  the  pathname  to  the  local  MBone  storage  directory  and  select  a  session. 
Figure  C.2  shows  the  “Open  Session”  window. 


Figure  C.2.  Open  Session 
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IMPORT  A  SESSION  FROM  THE  SESSION  DIRECTORY 


This  is  probably  the  easiest  way  to  get  started.  If  you  have  sd  running,  it  creates  a 
file  .  sd_cache  in  your  home  directory  (you  might  need  to  quit  and  restart  sd  in  order  to 
get  an  updated  version  of .  sd_cache).  The  MBone  VCR  can  read  and  interpret  this  file 
and  create  a  VCR-session  out  of  it.  Just  click  on  "Import  SD  Session"  in  the  "Session" 
menu  and  choose  from  one  of  the  sessions.  Figure  C.3  shows  the  “Open  Session” 
window.  VCR  will  ask  you  for  a  filename  after  you  have  chosen  a  session  (it  creates  a 
default  filename  out  of  the  session  name  so  you  might  just  want  to  select  an  appropriate 
directory).  Click  OK  and  you  are  ready  to  record  this  session.  Since  the  sessions  in  sd 
often  only  include  one  media,  you  might  need  to  edit  the  session  to  add  more  media  from 
sd-sessions  to  your  VCR-session  (see  below  for  more  information).  If  you  are  using  sdr 
you  will  have  to  manually  create  a  new  VCR  session  using  the  same  address  and  port 
numbers  as  the  sdr  session  you  want  to  record. 
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Import  Session  from  SD 
Last  -/.sd_cache  update:  Thu  Aug  2211:28:55  1996 


Sessions: 

. ■;“■;■■■ . 

iSiGGRAPH  9^RML  tech  SIG 
5IGGRAPH  VRML  SIG 


a 


Media  tist  of  session: 


"NPS  AUV" 


I  audio  (rat)  224.2.205.190/18574/  0/16 
I  video  (vit^  224.2.205.190/64262/0/16 


import  Session 


Dismiss 


Figure  C.3.  Import  Session 
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CREATE  A  SESSION 


To  create  a  new  (empty)  session  a  user  can  either  use  the  "New  Session..."  entry  in 
the  "Session"  menu  or  double  click  in  the  empty  media  list  below  the  "No  session"  label. 

If  you  create  a  session  manually,  a  session  name  and  an  optional  session  description  have 
to  be  specified  in  the  "New  Session"  window  (Figure  C.4).  The  "Max  Scope"  defines  the 
maximum  scope  for  all  media  included  in  this  session.  To  add  a  new  media  to  the  session 
click  on  the  "Add  Media"  button. 

In  the  "Add  Media"  window  (Figure  C.5)  a  media  name  and  an  optional  media 
description  as  well  as  the  multicast  address,  the  port  number,  the  conference  id  (only 
needed  for  RTPvl  and  vat),  the  protocol  (RTF  or  vat)  and  the  scope  for  this  media  need 
to  be  specified.  Specifying  a  media  command  which  will  be  used  by  the  "Start  Session 
Tools"  function  in  the  "Tools"  menu  to  start  the  appropriate  application  for  this  media  is 
optional.  At  the  end,  a  session  file  name  (which  has  to  end  with  ".VCR")  has  to  be  given 
to  the  session.  Clicking  on  the  "Session  Filename"  button  Avill  open  a  file  selection  box  to 
choose  a  directory  and  filename. 
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Media  Name: 


jt^i^Desc:  Jl 


IP  Address:  ;1 


Portnumber: 


Confid:  itO 


Figure  C. 5.  Add  Media 
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IMPORT  MULTIPLE  SESSIONS  FROM  THE  SESSION  DIRECTORY 

With  the  "Import  Session  from  SD"  entry  in  the  "Session"  menu  one  can  only 
import  a  single  sd  session.  Sometimes,  however,  media  that  belong  to  one  session  are 
announced  in  different  sd-sessions.  To  be  able  to  record  such  sessions  and  rather  than 
creating  a  VCR-session  "by  hand,"  one  can  use  the  "Import  Session  from  SD"  button  in 
the  "New  Session"  window  to  compose  your  VCR-session  out  of  one  or  more  sd-sessions. 
In  the  "Import  Session  from  SD"  window  you  will  get  two  lists,  a  session  list  and  a  media 
list.  These  lists  include  all  the  sessions  and  media  found  in  your  ~/ .  sd  cache  file.  The 
media  list  always  displays  the  media  of  the  selected  session.  If  you  select  a  different 
session,  the  media  list  will  be  updated  automatically. 

You  can  import  an  entire  sd  session  (which  is  a  session  title,  a  session  description, 
a  generated  session  filename  and  all  media  supported  by  VCR)  by  clicking  on  the  "Get 
Session"  button  or  double  clicking  on  a  session  entry  in  the  session  Ust.  You  can  also  only 
import  a  session  title  (together  with  a  session  description  and  a  generated  session 
filename)  with  the  "Get  Title"  button  (or  by  double  clicking  with  mouse  button  2  on  a 
session  entry  in  the  session  fist).  Another  possibility  is  to  add  one  or  more  media  from 
sd-sessions  to  your  existing  VCR-session.  To  do  this,  you  can  select  a  media  in  the  media 
list  and  then  click  on  the  "Add  Media"  button  (or  just  double  click  on  a  media  entry  in  the 
media  list). 
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EDIT  A  SESSION  OR  MEDIA 


After  a  session  is  loaded/created,  the  session  name  and  a  list  of  media  is  displayed 
in  the  status  area.  Double  clicking  on  the  session  name  will  have  the  same  effect  as  the 
"Edit  Session..."  entry  in  the  "Session"  menu.  Double  clicking  on  one  of  the  media  in  the 
media  list  will  have  the  same  effect  as  the  "Edit  Media"  button  in  the  "Edit  Session" 
window  (Figure  C.6).  The  “Edit  Media”  window  is  shown  in  Figure  C.7. 


Edit  Media 


Media  Name: 


Media  Desc: 


IP  Address; 

5224.2.21646  i 

Portnumber: 

[28906" 

i 

Confid: 

fQ~— 

1 

Protocol: 

RTP  «  1 

Media  Command:! 

;  <■<  1 

Scope: 

,,  host 

site  region  ■■  4/  1 

Ok 

Cancel 

Figure  C.7.  Edit  Media 


78 


MUTE  A  MEDIA 


A  single  click  with  the  left  mouse  button  in  the  media  list  will  select  a  media  so  it 
can  be  muted/unmuted  with  the  "mute/unmute"  button  below  the  media  list.  If  the  media 
is  muted,  it  is  shown  as  "<media>"  instead  of  "media."  If  more  than  one  media  is  selected, 
the  "mute/unmute"  button  will  toggle  the  mute  state  for  all  selected  media  according  to 
their  mute  state.  Clicking  on  a  media  entry  with  the  middle  mouse  button  will  toggle  its 
mute  state,  clicking  in  the  media  list  with  the  right  mouse  button  will  unselect  all  selected 
media.  The  mute/unmute  interface  is  shown  in  Figure  C.8. 

Web  Content 

audio  I 

video  i  I 


mute/unmutel 


Figure  C. 8.  Mute/Unmute  Interface 


RECORD  A  SESSION 

To  record  a  session,  you  need  to  enable  recording  with  the  "Recording  Enabled" 
entry  in  the  "Record"  menu  (this  step  is  important  and  easy  to  forget).  By  default,  MBone 
VCR  does  not  start  to  record  if  it  does  not  receive  a  data  signal  from  any  of  the  media  in 
the  session.  To  start  recording  even  when  no  data  is  present,  select  the  "Start  recording 


without  signal"  checkbutton  in  the  "Record”  menu.  To  start  recording  click  on  the 
"record"  button  (third  button  from  the  left  in  Figure  C.9).  Click  the  "stop"  button  (fourth 
button  from  the  left  in  Figure  C.9)  to  stop  the  recording.  In  a  non-empty  session  you  can 
only  append  data  so  you  have  to  go  to  the  very  end  to  continue  recording. 


Hi  ^ 


►  i  m  N 


Figure  C.9.  MBone  VCR  Function  Buttons 


Note: 

In  order  to  record  your  own  signal,  some  tools  require  that  the 
MBone  VCR  runs  on  a  different  host  than  these  tools  since  they  do  not 
do  local  loopback  of  the  multicast  address/port  combinations  (e.g.  vat 
and  vie).  Therefore  the  "Start  Session  Tools"  window  from  the 
"Session"  menu  offers  an  entry  field  "Start  tools  on  host"  that  will  start 
the  tools  with  an  rsh  command  on  the  specified  remote  host.  For  this 
case  it  is  required  that  your  -/  .  r hosts  file  allow  such  operations. 

Since  MBone  VCR  does  local  loopback,  you  do  not  need  to  run  it 
on  a  different  host  than  the  session  tools  if  you  only  want  to  play  a  session 
back.  In  this  case  you  could  set  the  scope  to  0  (host)  so  you  won't  send  out 
any  data  to  the  network. 

The  "Stop  Session  Tools"  entry  in  the  tools  menu  will  allow  you  to 
stop  the  started  tools.  It  will  look  for  the  processes  in  the  process  table 
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(regardless  whether  they  were  started  on  the  local  or  a  remote  host)  and  if 
they  still  run,  it  will  send  them  a  kill  signal  to  stop. 


PLAY  A  SESSION 

To  play  a  session  back  you  simply  click  on  the  "play"  button  (third  button  from  the 
right  in  Figure  C.9).  In  order  to  listen  and/or  watch  the  data  you  need  to  run  the 
corresponding  MBone  tools.  These  can  be  launched  directly  from  within  the  MBone  VCR 
with  the  "Start  Session  Tools"  window  in  the  "Tools"  menu.  If  the  option  "Autostart 
Session  Tools"  in  the  "Tools"  menu  is  selected,  the  "Start  Session  Tools"  window  will 
automatically  appear  when  the  user  plays  a  session  for  the  first  time. 

FAST  FORWARD  AND  REWIND 

To  fast  forward  (ff)  or  rewind  (rew)  a  session  you  can  click  on  the  "fif '  button 
(second  from  the  left  in  Figure  C.9)  or  the  "rew"  button  (second  from  the  right  in  Figure 
C.9).  The  speed  with  which  the  session  will  be  forwarded/rewound  can  be  changed  with 
the  "FF/REW  factor .."  entry  in  the  "Options"  menu. 

RANDOM  ACCESS  WITH  THE  SESSION  SLIDER 

The  slider  on  the  very  bottom  of  the  interface  (shoAvn  in  Figure  C.  10)  enables 
random  access  within  the  session.  Clicking  with  the  middle  mouse  button  somewhere  in 
the  slider  will  forward  or  rewind  the  session  to  this  point.  Clicking  the  left  mouse  button 
on  the  slider  left  from  the  marker  will  rewind  the  session  one  second,  clicking  the  left 
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mouse  button  right  from  the  marker  will  forward  the  session  one  second.  If  the  right 
mouse  button  is  clicked  an5where  on  the  slider  the  session  playback  will  pause  until  the 
button  is  released.  At  the  lower  right  comer  the  total  length  of  the  session  is  displayed. 
Clicking  in  this  field  will  forward  to  the  end  of  the  session. 


Seconds 


Figure  C.IO.  Random  Access  Slider 


JTotal  time:i;i 
■  00:09:59  | 


PLAYING  AT  VARIOUS  SPEEDS 

To  change  the  playback  speed  you  can  select  "double  speed"  or  "half  speed"  in  the 
"Speed"  menu.  Note  that  this  feature  is  not  available  for  all  data  formats.  If  multiple 
speeds  for  a  format  is  not  supported,  you  might  mute  the  media  to  listen/watch  at  least  the 
other  media  at  double/half  speed. 


LOOP  MODE 

If  the  "Loop  Mode"  entry  in  the  "Options"  menu  is  checked  during  playback,  the 
session  will  start  all  over  from  the  beginning  when  it  reaches  the  end.  This  feature  allows 
continuously  transmitting  a  session. 


INDICES 

The  MB  one  VCR  provides  a  number  of  different  indices.  Basically  there  are  two 
categories  of  indices;  automatically  generated  indices  (AGI)  and  user  defined  indices 
(UDI). 
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AGIs  are  automatically  generated  by  MBone  VCR  during  recording.  Examples  for 
AGIs  are  "next  speaker",  "next  sync  unit"  or  "new  format."  UDIs  can  be  set  by  the  user 
either  during  recording  or  afterwards.  There  are  five  levels  of  UDIs  so  a  user  can  use 
different  levels  for  different  purposes.  To  get/set/delete  indices  you  can  use  the  "Index 
Control  Panel"  by  clicking  on  "Toggle  indexcontrolpanel".  The  "Idxmode"  menu  will 
change  the  behavior  of  the  leftmost  and  the  rightmost  button  in  the  main  window  so  you 
can  select  which  function  these  buttons  actually  perform.  This  portion  of  the  user 
interface  is  shown  in  Figure  C.  1 1 . 

Idxmodelgoto  start/ end  ildxmedia:j- 

i  Toggle  indexcontrol  panel  | 

Figure  C.  1 1 .  Index  Control  Interface 

Note: 

Indices  are  always  media  specific  so  you  have  to  specify  an  index 
media  with  the  "Idxmedia"  menu  on  which  the  index  functions  are 
performed.  You  can  always  change  this  media  but  you  won't  see  indices  set 
on  one  media  if  you  have  selected  another. 


BLANK  SKIP  /  AUTO  BLANK  SKIP 

One  of  the  options  in  the  "Idxmode"  menu  is  "blank  skip."  This  feature  will  skip 
blank  gaps  of  the  specified  length  in  the  media  selected  by  the  "Idxmedia"  menu  and 
forward  the  session  to  the  beginning  of  the  next  data.  "Blank  Skip"  and  "Auto  Blank 
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Skip"  are  basically  the  same,  the  only  difference  is  that  during  playback  "Auto  Blank  Skip" 
will  automatically  detect  and  skip  blank  areas  in  the  media  selected  by  "Idxmedia." 


VCR  MACRO  COMMANDS 

The  VCR  macro  commands  provide  limited  control  to  record  and  playback 
sessions  during  ofiF-hours  or  to  write  macros  for  demo  purposes.  The  supported 
commands  are: 


load 

unload 

play 

rec 

ff 

rew 

stop 

at 

HHrMMzSS 

MM/DD/YY 

wait 

[  [  [HH:  ]MM:  ]SS] 

speed 

normal 

double 

half 

goto 

end 

start 

secs 

next_index 

idx 

prev_index 

idx 

next_blank 

ms 

prev_blank 

ms 

mute 

media_nb 

(0. . . nb_of_media“l ) 

auto^start 

on  I  off 

blink 

on  I  off 

idx^media 

media_nb 

auto_blank 

ms 


loop 

on  I  off 

rec_enabled 
on  I  off 
start_rec 

on_signal  |  no_signal 

f  f_rew_f  actor 
value 
start_tools 
stop^tools 
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These  commands  are  documented  in  the  VCR  man  page  and  can  be  used  in  a 
command  file  passed  to  the  VCR  applications  by  the  "-c"  command  line  parameter.  A 
macro  file  can  also  be  read  with  the  "Run  Macro  File"  entry  in  the  "Macro"  menu.  The 
commands  will  be  executed  sequentially,  a  "wait"  command  will  wait  for  hh;mm:ss  until 
the  next  command  is  read,  an  “at”  command  (if  not  too  late)  will  wait  until  the  specified 
time/date.  An  example  for  playback  might  look  hke  this; 

#  load  a  demo  session  (recorded  earlier) 
load  ~/VCR-data/demo.vcr 

#  goto  position  10  min. 
goto  600 

#  start  playing 
play 

#  play  for  5  min. 
wait  5:00 

#  stop  playing 
stop 

The  macro  commands  can  also  be  used  to  automatically  start  recordings  at  a  specific 
time/date  as  in: 

#  load  a  demo  session  (created  earlier) 
load  ~/VCR-data/demo . vcr 

#  start  the  session  tools 
start_tools 

#  goto  end  (recording  is  only  allowed  at  the  end!) 
goto  end 

#  enable  recording 
rec_enabled  on 

#  start  recording  at  1:45pm  on  May  20th  1995 
at  13:45:00  05/20/95 

#  start  recording 
rec 

#  record  for  1  hour  and  30  mins, 
wait  1:30:00 

#  stop  recording 
stop 

#  close  the  session  tools 
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stop_tools 

#  quit  the  MBone  VCR 
quit 

Or  another  example  could  be  to  playback  sessions  of  a  conference  recording  at  a  specific 
time/date  as  in: 

#  no  loop  mode 
loop  off 

#  start  playing  at  12:00pm  on  May  20th  1995 
at  12:00:00  05/20/95 

#  load  confl  session 
load  ~/VCR-data/conf 1 .VCR 

#  start  playing 
play 

#  play  for  1.5  hours 
wait  01:30:00 

#  stop  playing 
stop 

#  unload  confl 
unload 

#  start  playing  at  2:00pm  on  May  20th  1995 
at  14:00:00  05/20/95 

#  load  conf2  session 
load  ~/VCR-data/conf2.VCR 

#  start  playing 
play 

#  play  for  1.5  hours 
wait  01:30:00 

#  stop  playing 
stop 

#  quit  VCR 
quit 

For  example,  this  macro  could  be  stored  in  a  file  confl-2.cmd  and  than  executed  by 
running: 

VCR  -c  confl-2.cmd 
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KNOWN  BUGS/SHORTFALLS 


This  research  used  an  early  version  of  the  MBone  VCR  thanks  to  the  enthusiastic 
and  expert  support  of  Wieland  Holfelder.  This  section  delineates  the  know  bugs  and  some 
of  the  shortcomings  of  the  MBone  VCR  that  will  hopefully  be  corrected  in  future  versions 
of  the  tool. 

♦Not  compatible  with  sdr  except  by  manually  entering  proper  address/port 
numbers. 

♦No  rat  compatibility  as  of  this  writing,  important  for  redundant  encodings  (FEC) 
of  audio. 

♦RTF  Sender  Reports  and  RTF  Receiver  Reports  not  yet  implemented. 

♦Whiteboard  (wi)  not  yet  supported. 

♦No  bandwidth  limiting  during  playback,  may  be  useful  in  global  (ttl=127) 
sessions. 

♦Additional  recording  is  only  possible  at  the  end  of  a  session. 

♦Double  and  half  speed  not  yet  supported  for  all  data  formats  (may  not  be 
possible). 

♦TCL/TK  support  should  be  statically  linked  in  binaries  to  eliminate  need  for  users 
to  download  TCL/TK  libraries. 
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APPENDIX  D.  NFS  CAMPUS  NEWS  ARTICLES  ABOUT  IIRG  AND 
CONTENT  AND  ACCESS  WORKSHOP 


September  6, 1996  --  Profs,  Students  Continue  MBone  Development 

by  Dale  Kuska 

In  the  hit  movie  Back  to  the  Future,  Dr.  Emmitt  Brown  took  a  DeLorean  sports  car,  a  few 
odds  and  ends  in  his  garage,  added  a  little  innovation  and  ingenuity,  and  created  a  time  machine 
with  little  money. 

Professors  and  students  here  at  NPS  have  accomplished  a  similar  feat.  They  took  a 
connection  to  the  information  super-highway,  computer  hardware,  software  and  equipment  that 
already  existed  on  campus,  also  used  some  innovation  and  ingenuity,  and  created  a  high-speed 
Internet  classroom  at  a  very  low  cost. 

While  we  may  not  be  able  to  travel  through  time,  the  classroom  does  take  advantage  of 
developing  technology,  the  Multicast  Backbone  (MBone)  which  allows  NPS  to  broadcast  classes 
over  the  Internet  to  destinations  all  over  the  world.  "We  want  to  use  the  MBone  more  and  more 
because  of  its  broad  applicability  across  the  Internet,  the  fact  that  we  can  access  a  lot  of  people," 
said  Professor  Don  Brutzman.  "We  would  like  to  be  able  to  teach  classes  here  and  have  them 
accessible  to  the  Navy  over  the  Internet." 

In  order  to  increase  development  of  the  MBone,  Brutzman  says  the  clear  thing  to  do  was 
create  a  group  of  professors  and  students  aimed  at  doing  just  that.  So  began  the  Information 
Infrastructure  Research  Group  (iirg@stl.nps.navy.mil)  and  one  of  their  first  orders  of  business  was 
to  create  a  dedicated  MBone  classroom.  How  to  do  that  was  a  question  that  needed  answering. 

"Our  usual  answer  to  a  question  of,  how  do  you  do  something,'  is  to  simply  do  it;  so  we 
did,"  explained  Brutzman.  "We  looked  around  campus  to  see  what  was  available  to  us.  We 
found  a  workstation  that  had  a  projector  capability.  We  got  a  network  connection  into  the 
classroom,  so  that  was  a  start.  From  then  on,  it  was  fairly  straightforward  stepping  through  our 
previous  lessons  learned.  We  added  a  camera  and  wireless  microphone.  We  wanted  to  make  the 
teaching  as  natural  as  possible,  so  we  added  an  overhead  transparency  screen." 

But  alterations  to  the  classroom  didn't  stop  there,  added  Brutzman.  Public  Works 
installed  a  second  screen  and  added  another  light  switch,  giving  the  group  more  control  over  the 
lighting.  "Again,  this  is  something  that  didn't  cost  us  any  money.  We  just  asked  Public  Works  to 
do  something  they  are  here  to  do  and  do  very  well,"  said  Brutzman. 

NPS's  video-teleconferencing  classrooms  offered  the  IIRG  a  working  model,  Brutzman 
said.  "We  have  learned  from  looking  at  the  distance  learning  classroom  down  (in  Root)  hall,  and 
we  tried  to  incorporate  what  we  learned.  But  we  intentionally  wanted  to  use  assets  that  already 
existed  here  at  the  school,  not  spend  money,  and  move  forward,  and  now  I  think  we  have  a 
working  product,"  he  added. 

The  IIRG  has  not  only  put  together  a  working  on-line  classroom,  but  continues 
researching  all  areas  of  MBone  and  network  technologies.  "It  appears  we  can  send  over  a 
128kbit/sec  ISDN  line.  Marine  Corps  Maj.  Lauren  Million's  thesis  is  trying  to  show  that.  We  now 
can  record  MBone  digitally  and  put  them  on-line  for  retrieval.  (Marine  Corps  Capt.)  Mike 
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Tiddy's  thesis  is  showing  that.  (Turkish  navy  Lt.  j.g.)  Murat  Tamer's  thesis  is  documenting  that 
you  can  move  all  this  equipment  to  an  auditorium  or  conference  on  a  wireless  link  Basic^ly,  that 
this  is  like  a  mobile  classroom  because  you  can  pick  it  up  and  use  it  in  another  location  the  next 
day.  (Turkish  navy  Lt.  j.g.)  Ridvan  Erdogan's  thesis  is  showing  we  can  send  MBone  audio  and 
video  to  local  schools,  even  over  their  relatively  slow  connection  lines.  He's  worked  with  the 
county  office  of  education  in  Salinas  and  a  school  in  Soledad,"  explained  Brut2man. 

"We've  also  had  a  student  looking  at  how  we  can  internetwork  the  whole  Marine  Corps 
and  Capt.  Jim  Nierle  laid  it  out  in  complete  detail.  That  was  a  very  exciting  thesis  because  of  the 
possibilities  it  may  bring,"  he  adds.  "The  main  thing  is  that  our  thesis  projects  some  what  support 
each  other,  and  the  group  allows  us  to  meet  and  discuss  similar  problems,  so  that  we're  not  trying 
to  reinvent  the  wheel." 

Brutzman  feels  that  internetworking  is  clearly  the  wave  of  the  future  in  the  Navy.  "When 
a  ship  pulls  in  and  ties  up  next  to  the  pier,  double-up  the  lines,  hooks  up  to  shore  power,  hooks  up 
to  shore  telephone,  the  next  thing  on  their  check  list  ought  to  be  hook  up  to  the  shore  Internet 
connection.  That  way  the  ship's  Local  Area  Network  is  connected  to  the  global  Internet  or  the 
Navy's  Internet.  We  think  it  is  inevitable  that  these  things  are  going  to  emerge,"  Brutzman 
explained. 

"The  best  example  of  that  is  how  we  do  business  right  here  at  NPS.  There's  probably  not 
a  person  on  this  campus  that  isn't  impacted  positively  by  our  campus  network  in  their  everyday 
work.  You  couldn't  rip  it  out  of  this  campus  if  you  wanted  to,  it's  that  powerful.  And  there's  no 
reason  to  think  it  won't  be  equally  as  powerful  and  just  as  useful  on  Navy  ships." 

There  are  hurdles,  however,  to  make  MBone  technology  accessible  to  any  Sailor. 
Brutzman  feels  that  when  Local  Area  Networks  are  implemented  on  ships,  the  door  will  be  open 
for  MBone  technology  to  fleet  sailors  worldwide,  and  "we  just  want  to  be  ready." 


August  30, 1996  ~  Web  Builders  Share  "High  Technology"  Projects,  Lessons 
Learned 

by  Barbara  Honegger 

On  August  26,  the  13 LA  Content  and  Access  (ConAcc)  Team  —  a  regional  network  of 
computer  engineers,  educators,  researchers,  and  librarians  -  gathered  at  NPS  for  a  two-day 
"learning  workshop"  on  building  content  and  access  on  the  World  Wide  Web.  The  Web  is  a 
subset  of  the  Internet,  the  worldwide  network  of  computer  networks. 

Despite  the  imposing  name  -  I3LA  stands  for  Initiative  for  Information  Infrastructure  and 
Linkage  Applications  -  members  of  the  all-volunteer  ConAcc  team  stress  the  informality  of  their 
working  group. 

"The  ConAcc  Team  is  really  just  a  way  for  anyone  interested  in  developing  Web  content 
and  access  to  learn  from  and  help  each  other,"  said  Victoria  Welbom,  head  of  the  Science  Library 
at  U.C.  Santa  Cruz  and  coordinator/facilitator  for  the  group.  "We  meet  once  a  month,  but  there's 
never  enough  time  to  really  get  into  the  specifics  of  each  other's  projects,"  she  said.  "So  we 
decided  to  get  together  for  a  longer  period  of  time  for  members  to  'show  and  tell'  what  they've 
been  doing  ~  which  became  the  workshop." 
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An  exciting  'show  and  tell'  it  was.  Members  not  only  discussed,  but  in  many  cases 
demonstrated,  their  "examplar"  web  projects,  including  "Networked  Ocean  Science  Research  and 
Education,  Monterey  Bay";  a  mobile,  online  classroom  using  a  "telemation"  vehicle;  "A  Place  of 
Our  Own"  -  a  branch  of  the  Santa  Cruz  library  system  set  aside  just  for  teenagers,  to  do 
homework  and  use  computers;  the  Monterey  Bay  Area  Cooperative  Library  System;  and  panels 
on  reducing  barriers  to  access,  how  to  build  user-interactive  web  pages,  curriculum  questions  and 
Internet  trmning  for  faculty  and  students. 

"Our  members  were  both  pleased  and  proud,"  said  Welbom.  "Attendance  was 
impressive-  over  40  on  the  first  day  and  20  on  the  second  -  and  we  achieved  all  of  our  main 
goals;  to  educate  and  motivate  each  other,  increase  visibility  and  regional  awareness  for  the 
network,  recruit  new  members,  and  show  how  the  technology  actually  works." 

Throughout  the  woikshop,  for  instance,  presenters  were  able  to  project  their  Web  sites 
and  home  pages  "live"  onto  an  overhead  screen  using  an  LCD  panel,  thanks  to  the  efforts  of  NPS 
professor  Don  Brutzman  and  his  dedicated  team  of  students  who  manned  the  projection  booth. 
They  also  provided  a  demonstration  of  "live"  audio  and  video  over  the  Internet  using  the 
"Multicast  Backbone"  (Mbone). 

"Don  Brutzman  is  part  of  the  heart  and  soul  of  this  effort,"  said  Welbom.  "Without  him, 
none  of  it  would  have  happened  so  soon,  or  nearly  so  well." 

I3LA  and  its  three  teams  —  network  design,  education  and  content-access  —  formed  two 
years  ago  when  Pacific  Bell  agreed  to  provide  fi’ee  wiring  into  schools,  research  labs  and  libraries 
in  Monterey  and  Santa  Cruz  Counties  and  two  years  of  free  telephone  service  for  Internet  users  at 
the  wired  sites.  Local  institutions  were  quick  to  take  advantage  of  this  California  Research  and 
Education  Network  (CALREN)  agreement,  creating  a  regional  network  connecting  K-12  schools, 
colleges,  universities,  museums,  libraries,  government  agencies  and  research  institutions  in  the 
two-county  area. 

So  far,  the  regional  network,  called  Monterey  BayNet,  has  connected  most  users  around 
the  common  theme  of  environmental  and  ocean  science,  providing  full  Internet  access  via  text, 
h5fpertext,  multimedia,  audio  and  video.  Forty  five  schools,  libraries  and  colleges  now  have 
medium-speed  links,  and  ten  universities  and  research  institutions  high-speed  connections,  in  the 
two  counties. 

"Although  the  initial,  and  therefore  most  developed,  focus  has  been  on  science  and  ocean 
topics,"  said  Welbom,  "it  is  just  that,  a  focus.  It's  not  a  limitation.  People  are  free  to  use  the 
Internet,  individually  or  in  teams,  to  look  at  anything  they  want  to." 

"This  broad-based,  collaborative  effort  teams  education,  science,  business  and  government 
to  fundamentally  improve  our  schools,"  said  Bmtzman,  a  key  member  of  all  three  I3LA  teams. 
"Now  that  the  connectivity  is  there,  our  mission  is  to  promote  practical  uses  for  the  network,  and 
to  serve  users,  creators  and  managers  of  data  and  information  by  facilitating  access,  building 
content,  evaluating  resources  and  maintaining  collection." 

The  broad  reach  of  the  regional  network  can  be  seen  from  the  list  of  workshop  attendees 
and  participants,  which  included  representatives  from  UCSC;  NPS;  DLI;  CSU;  MIIS;  Cabrillo 
College;  AMBAG;  Monterey  County;  San  Juan  Batista,  Carmel,  Santa  Cruz  County  and 
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Monterey  Bay  Area  Cooperative  libraries;  PRC;  MBARI;  the  Monterey  Bay  Aquarium;  the 
Monterey  Bay  National  Marine  Sanctuary;  Moss  Landing  Marine  Labs;  Santa  Cruz  County  OflBce 
of  Education;  Monterey  Bay  Online;  and  The  Creative  Edge. 

According  to  Brutzman,  "people"  challenges  have  been  and  continue  to  be  as  important  as 
technical  ones  in  creating,  building  and  maintaining  the  regional  Internet  system. 

"One  of  our  mottos  is,  'Technical  problems  have  technical  solutions,  and  people  problems 
have  people  solutions,"'  he  said.  "Our  goal  is  to  make  the  high-tech  Internet  available  and  useful 
to  real  people  in  real  jobs,  every  day." 

In  a  few  weeks,  the  job  of  maintaining  the  network  may  become  a  lot  harder.  As  of 
October  1,  the  two-year  CALREN  agreement  under  which  Pac  Bell  provided  free  wiring  and 
phone  time  expires. 

"We're  at  a  very  exciting  junction  after  two  years  of  free  connectivity,"  said  Bruzman. 
"We're  going  to  have  to  find  sustainable  ways  of  keeping  the  schools  coimected.  And  now  that 
we  have  a  network,  that's  more  important  than  ever."  Anyone  interested  in  joining  the  Content 
and  Access  Team,  or  with  ideas  about  how  to  keep  the  network  vital  and  growing,  is  invited  to 
contact  Welbom  at  459-2816,  or  e-mail  <welbom@cats.uscs.edu>  or  <i31a_conacc@mbari.org>. 
More  information  about  the  workshop  is  available  at: 

<http.7/www.stl.nps.navy.niil/~brutzman/workshop.html>.  And  if  you  missed  the  workshop,  you 
can  still  see  the  "live"  audio  and  visual  MBone  in  operation  by  dropping  by  Root  Hall  Room  204 
this  Saturday,  Sept.  14,  Discovery  Day,  between  10  a  m.  and  3  p.m. 
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